From owner-freebsd-net@FreeBSD.ORG Sun Sep 6 00:48:43 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 723031065672 for ; Sun, 6 Sep 2009 00:48:43 +0000 (UTC) (envelope-from stef-list@memberwebs.com) Received: from mail.npubs.com (mail.npubs.com [74.82.45.72]) by mx1.freebsd.org (Postfix) with ESMTP id 643148FC12 for ; Sun, 6 Sep 2009 00:48:43 +0000 (UTC) Resent-Message-Id: From: Stef Walter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Boris Kochergin References: <4A8C3557.20002@acm.poly.edu> <4AA03A41.1080200@acm.poly.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Resent-Date: Sun, 6 Sep 2009 00:48:43 +0000 (UTC) Resent-From: stef-list@memberwebs.com Cc: freebsd-net@freebsd.org Subject: Re: kmem_map too small panics with Soekris/Atheros access point X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stef@memberwebs.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sun, 06 Sep 2009 00:48:43 -0000 X-List-Received-Date: Sun, 06 Sep 2009 00:48:43 -0000 Boris Kochergin wrote: >> _______________________________________________ >> 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" > More information: I upgraded it to a 7.2-STABLE with August 20th sources > and increased kern.ipc.nmbclusters to 65536 in hopes of getting the > panic less often. I managed to catch it in a state where there were a > bunch of "ath0: ath_rx_proc: no mbuf!" messages in the kernel buffer. > One line of "vmstat -m" stood out as the leak: > > 80211node 12677 101401K - 120901 16,512 > > "ifconfig ath0 down" freed the memory. Is there any other useful > information I can provide if I catch it again? Someone suggested the > output of "vmstat -z" off list, and I will have that next time. This might be a long shot: Back when I deployed some similar devices on FreeBSD 6.0 there was a leak when using oddball ath_rate driver. I believe it went away when I used ath_rate_sample. But according to 'man 4 ath' nothing else besides ath_rate_sample exists anymore. Cheers, Stef From owner-freebsd-net@FreeBSD.ORG Sun Sep 6 20:06:25 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C46421065679; Sun, 6 Sep 2009 20:06:25 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from no.spam.no.ddos.ru (no.spam.no.ddos.ru [77.73.233.132]) by mx1.freebsd.org (Postfix) with ESMTP id 5440C8FC08; Sun, 6 Sep 2009 20:06:23 +0000 (UTC) Received: from ws.ipfw.ru (secured.by.ipfw.ru [81.200.11.182]) by no.spam.no.ddos.ru (Postfix) with ESMTPA id 1833B37A708; Sun, 6 Sep 2009 19:46:27 +0000 (UTC) Message-ID: <4AA41192.6080708@ipfw.ru> Date: Sun, 06 Sep 2009 23:46:26 +0400 From: "Alexander V. Chernikov" User-Agent: Thunderbird 2.0.0.22 (X11/20090818) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary="------------010607050501030003050405" Cc: freebsd-isp@freebsd.org Subject: Call for testers: ng_netflow with v9 and IPv6 support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 20:06:25 -0000 This is a multi-part message in MIME format. --------------010607050501030003050405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi! There are patches for 7.2R and . to make ng_netflow export IPv4/IPv6 flows via V9 protocol (RFC3954). Your feedback is welcome. Alternative links: http://static.ipfw.ru/patches/netflow_v9_20090906_72.diff http://static.ipfw.ru/patches/netflow_v9_20090906_curr.diff node runtime control messages: Set export version: setversion { version=X }. X=[59], defaults to 9 Set export interface mtu setmtu { mtu=X }. X has to be <= MHLEN at the moment, defaults to 1500 Set v9 template announce conditions settemplateperiodic { time=X packets=Y }. Send templates every X seconds or Y packets, X=600, Y=500 by default --------------010607050501030003050405 Content-Type: text/plain; name="netflow_v9_20090906_curr.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netflow_v9_20090906_curr.diff" diff -urN sys/netgraph/_netflow.orig/netflow.c sys/netgraph/netflow/netflow.c --- sys/netgraph/_netflow.orig/netflow.c 2009-09-01 02:37:44.000000000 +0400 +++ sys/netgraph/netflow/netflow.c 2009-09-06 17:04:28.000000000 +0400 @@ -30,6 +30,8 @@ static const char rcs_id[] = "@(#) $FreeBSD: src/sys/netgraph/netflow/netflow.c,v 1.33 2008/12/15 06:10:57 qingli Exp $"; +#include "opt_inet6.h" + #include #include #include @@ -37,14 +39,18 @@ #include #include #include +#include #include +#include #include #include +#include #include #include #include +#include #include #include @@ -94,12 +100,99 @@ ((t) << 6) + /* 64 */ \ ((t) << 5) + /* 32 */ \ ((t) << 3)) /* 8 */ +/* + * Defines for different neflow version dispatchers + * + */ +static int export_add(item_p, struct flow_entry *); +static int export_add_v9(item_p, struct flow_entry *); +static int export_send(priv_p, item_p, int flags); +static int export_send_v9(priv_p, item_p, int flags); + +typedef int (*record_add_ptr)(item_p, struct flow_entry *); +typedef int (*record_send_ptr)(priv_p, item_p, int); +struct _netflow_dispatchers { + record_add_ptr record_add; + record_send_ptr record_send; +}; + +static struct _netflow_dispatchers netflow_dispatcher[] = +{ + { NULL, NULL }, + { NULL, NULL }, + { NULL, NULL }, + { NULL, NULL }, + { NULL, NULL }, + { export_add, export_send }, /* Version 5 */ + { NULL, NULL }, + { NULL, NULL }, + { NULL, NULL }, + { export_add_v9, export_send_v9 }, /* Version 9 */ + { NULL, NULL } +}; + +record_add_ptr record_add = NULL; +record_send_ptr record_send = NULL; MALLOC_DECLARE(M_NETFLOW_HASH); MALLOC_DEFINE(M_NETFLOW_HASH, "netflow_hash", "NetFlow hash"); -static int export_add(item_p, struct flow_entry *); -static int export_send(priv_p, item_p, int flags); + +static struct netflow_v9_template _netflow_v9_record_ipv4_tcp[] = +{ + { NETFLOW_V9_FIELD_IPV4_SRC_ADDR, 4}, + { NETFLOW_V9_FIELD_IPV4_DST_ADDR, 4}, + { NETFLOW_V9_FIELD_IPV4_NEXT_HOP, 4}, + { NETFLOW_V9_FIELD_INPUT_SNMP, 2}, + { NETFLOW_V9_FIELD_OUTPUT_SNMP, 2}, + { NETFLOW_V9_FIELD_IN_PKTS, sizeof(cntr)}, + { NETFLOW_V9_FIELD_IN_BYTES, sizeof(cntr)}, + { NETFLOW_V9_FIELD_OUT_PKTS, sizeof(cntr)}, + { NETFLOW_V9_FIELD_OUT_BYTES, sizeof(cntr)}, + { NETFLOW_V9_FIELD_FIRST_SWITCHED, 4}, + { NETFLOW_V9_FIELD_LAST_SWITCHED, 4}, + { NETFLOW_V9_FIELD_L4_SRC_PORT, 2}, + { NETFLOW_V9_FIELD_L4_DST_PORT, 2}, + { NETFLOW_V9_FIELD_TCP_FLAGS, 1}, + { NETFLOW_V9_FIELD_PROTOCOL, 1}, + { NETFLOW_V9_FIELD_TOS, 1}, + { NETFLOW_V9_FIELD_SRC_AS, 4}, + { NETFLOW_V9_FIELD_DST_AS, 4}, + { NETFLOW_V9_FIELD_SRC_MASK, 1}, + { NETFLOW_V9_FIELD_DST_MASK, 1}, + {0, 0} +}; + +static struct netflow_v9_template _netflow_v9_record_ipv6_tcp[] = +{ + { NETFLOW_V9_FIELD_IPV6_SRC_ADDR, 16}, + { NETFLOW_V9_FIELD_IPV6_DST_ADDR, 16}, + { NETFLOW_V9_FIELD_IPV6_NEXT_HOP, 16}, + { NETFLOW_V9_FIELD_INPUT_SNMP, 2}, + { NETFLOW_V9_FIELD_OUTPUT_SNMP, 2}, + { NETFLOW_V9_FIELD_IN_PKTS, sizeof(cntr)}, + { NETFLOW_V9_FIELD_IN_BYTES, sizeof(cntr)}, + { NETFLOW_V9_FIELD_OUT_PKTS, sizeof(cntr)}, + { NETFLOW_V9_FIELD_OUT_BYTES, sizeof(cntr)}, + { NETFLOW_V9_FIELD_FIRST_SWITCHED, 4}, + { NETFLOW_V9_FIELD_LAST_SWITCHED, 4}, + { NETFLOW_V9_FIELD_L4_SRC_PORT, 2}, + { NETFLOW_V9_FIELD_L4_DST_PORT, 2}, + { NETFLOW_V9_FIELD_TCP_FLAGS, 1}, + { NETFLOW_V9_FIELD_PROTOCOL, 1}, + { NETFLOW_V9_FIELD_TOS, 1}, + { NETFLOW_V9_FIELD_SRC_AS, 4}, + { NETFLOW_V9_FIELD_DST_AS, 4}, + { NETFLOW_V9_FIELD_SRC_MASK, 1}, + { NETFLOW_V9_FIELD_DST_MASK, 1}, + {0, 0} +}; + + +static int generate_v9_templates(priv_p priv); + +MALLOC_DECLARE(M_NETFLOW_GENERAL); +MALLOC_DEFINE(M_NETFLOW_GENERAL, "netflog_general", "plog, templates data"); /* Generate hash for a given flow record. */ static __inline uint32_t @@ -108,10 +201,24 @@ switch (r->r_ip_p) { case IPPROTO_TCP: case IPPROTO_UDP: - return FULL_HASH(r->r_src.s_addr, r->r_dst.s_addr, + return FULL_HASH(r->src.r_src.s_addr, r->dst.r_dst.s_addr, r->r_sport, r->r_dport); default: - return ADDR_HASH(r->r_src.s_addr, r->r_dst.s_addr); + return ADDR_HASH(r->src.r_src.s_addr, r->dst.r_dst.s_addr); + } +} + +/* Generate hash for a given flow record. Use lower 4 octets from v6 addresses */ +static __inline uint32_t +ip6_hash(struct flow_rec *r) +{ + switch (r->r_ip_p) { + case IPPROTO_TCP: + case IPPROTO_UDP: + return FULL_HASH(r->src.r_src6.__u6_addr.__u6_addr32[3], r->dst.r_dst6.__u6_addr.__u6_addr32[3], + r->r_sport, r->r_dport); + default: + return ADDR_HASH(r->src.r_src6.__u6_addr.__u6_addr32[3], r->dst.r_dst6.__u6_addr.__u6_addr32[3]); } } @@ -126,6 +233,7 @@ atomic_add_32(&priv->info.nfinfo_used, 1); + return (0); } @@ -141,6 +249,7 @@ /* * Detach export datagram from priv, if there is any. * If there is no, allocate a new one. + * -- V9/IPv6 ready */ static item_p get_export_dgram(priv_p priv) @@ -166,14 +275,163 @@ return (NULL); dgram = mtod(m, struct netflow_v5_export_dgram *); dgram->header.count = 0; - dgram->header.version = htons(NETFLOW_V5); + dgram->header.version = htons(priv->version); + + if (priv->version == NETFLOW_V9) { + atomic_fetchadd_32(&priv->sent_packets, 1); + + /* + * Let's insert mbuf tag to store some info + */ + struct netflow_v9_mbuf_tag *t; + struct m_tag *mt = m_tag_alloc(MTAG_NETFLOW, MTAG_NETFLOW_V9, sizeof(struct netflow_v9_mbuf_tag), M_NOWAIT); + if (mt == NULL) { + m_freem(m); + return (NULL); + } + + m_tag_init(m); + m_tag_prepend(m, mt); + t = (struct netflow_v9_mbuf_tag *)(mt + 1); + t->length = sizeof(struct netflow_v9_header); + t->count = 0; + t->mtu = priv->mtu; + t->flow_header = t->length; + + /* + * Check if we need to insert templates into packet + */ + + struct timespec ts; + struct netflow_v9_flowset_header *fl; + + getnanotime(&ts); + if ((ts.tv_sec >= priv->templ_time + priv->templ_last_ts) || (priv->sent_packets >= priv->templ_packets + priv->templ_last_pkt)) { + //vlog("INSERTING TEMPLATE: ts: %lu last: %u packets: %u last: %u delay: %u", ts.tv_sec, priv->templ_last_ts, priv->sent_packets, priv->templ_last_pkt, priv->templ_time); + atomic_store_rel_32(&priv->templ_last_ts, ts.tv_sec); + atomic_store_rel_32(&priv->templ_last_pkt, priv->sent_packets); + //vlog("ts: %lu last_t: %u last_p: %u delay: %u", ts.tv_sec, priv->templ_last_ts, priv->templ_last_pkt, priv->templ_time); + + fl = priv->v9_flowsets[0]; + bcopy(fl, (char *)dgram + t->length, ntohs(fl->length)); + + t->length += ntohs(fl->length); + t->flow_header = t->length; + t->count += priv->flowset_records[0]; + } + + } } return (item); } /* + * Pre-compiles flow exporter for all possible FlowSets + * so we can add flowset to packet via simple memcpy() + */ +#define __push(x) *p++ = htons((x)) +static int +generate_v9_templates(priv_p priv) +{ + uint16_t *p, *template_fields_cnt; + int cnt; + + int flowset_size = sizeof(struct netflow_v9_flowset_header) + + _NETFLOW_V9_TEMPLATE_SIZE(_netflow_v9_record_ipv4_tcp) + /* netflow_v9_record_ipv4_tcp */ + _NETFLOW_V9_TEMPLATE_SIZE(_netflow_v9_record_ipv6_tcp); /* netflow_v9_record_ipv6_tcp */ + + priv->v9_flowsets[0] = malloc(flowset_size, M_NETFLOW_GENERAL, M_WAITOK | M_ZERO); + if (priv->v9_flowsets[0] == NULL) + return (ENOMEM); + + + if (flowset_size % 4) + flowset_size += 4 - (flowset_size % 4); /* Padding to 4-byte boundary */ + + priv->flowsets_count = 1; + p = (uint16_t *)priv->v9_flowsets[0]; + *p++ = 0; /* Flowset ID, 0 is reserved for Template FlowSets */ + *p++ = htons(flowset_size); /* Total FlowSet length */ + + /* + * Most common TCP/UDP IPv4 template, ID = 256 + */ + *p++ = htons(0x100 + NETFLOW_V9_FLOW_V4_L4); + template_fields_cnt = p++; + for (cnt = 0; _netflow_v9_record_ipv4_tcp[cnt].field_id != 0; cnt++) { + *p++ = htons(_netflow_v9_record_ipv4_tcp[cnt].field_id); + *p++ = htons(_netflow_v9_record_ipv4_tcp[cnt].field_length); + } + *template_fields_cnt = htons(cnt); + + /* + * TCP/UDP IPv6 template, ID = 257 + */ + *p++ = htons(0x100 + NETFLOW_V9_FLOW_V6_L4); + template_fields_cnt = p++; + for (cnt = 0; _netflow_v9_record_ipv6_tcp[cnt].field_id != 0; cnt++) { + *p++ = htons(_netflow_v9_record_ipv6_tcp[cnt].field_id); + *p++ = htons(_netflow_v9_record_ipv6_tcp[cnt].field_length); + } + *template_fields_cnt = htons(cnt); + + + priv->flowset_records[0] = 2; + return (0); +} + +/* + * Switches version used for netflow export + * + */ +void +ng_netflow_switch_version(priv_p priv, int ver, int boot) +{ + item_p item = NULL; + + if ((ver != NETFLOW_V9) && (ver != NETFLOW_V5)) + return; + + if ((ver == priv->version) && (boot == 0)) + return; + + /* + * All new threads acquiring export datagram will wait for lock + * so we can change pointers. + * Existing threads with export datagram already held will call + * wrong export function which will do version check at the beginning + */ + + mtx_lock(&priv->export_mtx); + /* XXX: Need to be machine-independent here */ + record_add = netflow_dispatcher[ver].record_add; + record_send = netflow_dispatcher[ver].record_send; + //atomic_store_rel_ptr((unsigned long *)record_add, (unsigned long)netflow_dispatcher[ver].record_add); + //atomic_store_rel_ptr((unsigned long *)record_send, (unsigned long)netflow_dispatcher[ver].record_send); + item = priv->export_item; + priv->export_item = NULL; + mtx_unlock(&priv->export_mtx); + + if (ver == NETFLOW_V9) { + priv->templ_last_pkt = 0; + priv->templ_last_ts = 0; + } + + //vlog("NEW: add=%p send=%p", record_add, record_send); + + if (item != NULL) + (*netflow_dispatcher[priv->version].record_send)(priv, item, NG_NOFLAGS); + + if (boot) + log(LOG_DEBUG, "ng_netflow: v%d export started\n", ver); + else + log(LOG_DEBUG, "ng_netflow: export switched: v%d -> v%d\n", priv->version, ver); + priv->version = ver; +} + +/* * Re-attach incomplete datagram back to priv. * If there is already another one, then send incomplete. */ static void @@ -190,13 +448,14 @@ mtx_unlock(&priv->export_mtx); } else { mtx_unlock(&priv->export_mtx); - export_send(priv, item, flags); + (*record_send)(priv, item, flags); } } /* * The flow is over. Call export_add() and free it. If datagram is * full, then call export_send(). + * -- v9/IPv6 nearly ready */ static __inline void expire_flow(priv_p priv, item_p *item, struct flow_entry *fle, int flags) @@ -208,8 +467,8 @@ uma_zfree_arg(priv->zone, fle, priv); return; } - if (export_add(*item, fle) > 0) { - export_send(priv, *item, flags); + if ((*record_add)(*item, fle) > 0) { + (*record_send)(priv, *item, flags); *item = NULL; } uma_zfree_arg(priv->zone, fle, priv); @@ -234,11 +493,14 @@ * to be sure. */ static __inline int -hash_insert(priv_p priv, struct flow_hash_entry *hsh, struct flow_rec *r, +hash_insert(priv_p priv, struct flow_hash_entry *hsh, struct flow_rec *r, uint16_t eproto, int plen, uint8_t tcp_flags) { struct flow_entry *fle; struct sockaddr_in sin; +#ifdef INET6 + struct sockaddr_in6 sin6; +#endif struct rtentry *rt; mtx_assert(&hsh->mtx, MA_OWNED); @@ -257,6 +519,7 @@ bcopy(r, &fle->f.r, sizeof(struct flow_rec)); fle->f.bytes = plen; fle->f.packets = 1; + fle->f.proto = eproto; fle->f.tcp_flags = tcp_flags; fle->f.first = fle->f.last = time_uptime; @@ -265,46 +528,94 @@ * First we do route table lookup on destination address. So we can * fill in out_ifx, dst_mask, nexthop, and dst_as in future releases. */ - bzero(&sin, sizeof(sin)); - sin.sin_len = sizeof(struct sockaddr_in); - sin.sin_family = AF_INET; - sin.sin_addr = fle->f.r.r_dst; - /* XXX MRT 0 as a default.. need the m here to get fib */ - rt = rtalloc1_fib((struct sockaddr *)&sin, 0, 0, 0); - if (rt != NULL) { - fle->f.fle_o_ifx = rt->rt_ifp->if_index; - - if (rt->rt_flags & RTF_GATEWAY && - rt->rt_gateway->sa_family == AF_INET) - fle->f.next_hop = - ((struct sockaddr_in *)(rt->rt_gateway))->sin_addr; - - if (rt_mask(rt)) - fle->f.dst_mask = bitcount32(((struct sockaddr_in *) - rt_mask(rt))->sin_addr.s_addr); - else if (rt->rt_flags & RTF_HOST) - /* Give up. We can't determine mask :( */ - fle->f.dst_mask = 32; - - RTFREE_LOCKED(rt); - } - - /* Do route lookup on source address, to fill in src_mask. */ - bzero(&sin, sizeof(sin)); - sin.sin_len = sizeof(struct sockaddr_in); - sin.sin_family = AF_INET; - sin.sin_addr = fle->f.r.r_src; - /* XXX MRT 0 as a default revisit. need the mbuf for fib*/ - rt = rtalloc1_fib((struct sockaddr *)&sin, 0, 0, 0); - if (rt != NULL) { - if (rt_mask(rt)) - fle->f.src_mask = bitcount32(((struct sockaddr_in *) - rt_mask(rt))->sin_addr.s_addr); - else if (rt->rt_flags & RTF_HOST) - /* Give up. We can't determine mask :( */ - fle->f.src_mask = 32; + if (eproto == ETHERTYPE_IP) { + bzero(&sin, sizeof(sin)); + sin.sin_len = sizeof(struct sockaddr_in); + sin.sin_family = AF_INET; + sin.sin_addr = fle->f.r.dst.r_dst; + /* XXX MRT 0 as a default.. need the m here to get fib */ + rt = rtalloc1_fib((struct sockaddr *)&sin, 0, 0, 0); + if (rt != NULL) { + fle->f.fle_o_ifx = rt->rt_ifp->if_index; + + if (rt->rt_flags & RTF_GATEWAY && + rt->rt_gateway->sa_family == AF_INET) + fle->f.n.next_hop = + ((struct sockaddr_in *)(rt->rt_gateway))->sin_addr; + + if (rt_mask(rt)) + fle->f.dst_mask = bitcount32(((struct sockaddr_in *) + rt_mask(rt))->sin_addr.s_addr); + else if (rt->rt_flags & RTF_HOST) + /* Give up. We can't determine mask :( */ + fle->f.dst_mask = 32; + + RTFREE_LOCKED(rt); + } + + /* Do route lookup on source address, to fill in src_mask. */ + bzero(&sin, sizeof(sin)); + sin.sin_len = sizeof(struct sockaddr_in); + sin.sin_family = AF_INET; + sin.sin_addr = fle->f.r.src.r_src; + /* XXX MRT 0 as a default revisit. need the mbuf for fib*/ + rt = rtalloc1_fib((struct sockaddr *)&sin, 0, 0, 0); + if (rt != NULL) { + if (rt_mask(rt)) + fle->f.src_mask = bitcount32(((struct sockaddr_in *) + rt_mask(rt))->sin_addr.s_addr); + else if (rt->rt_flags & RTF_HOST) + /* Give up. We can't determine mask :( */ + fle->f.src_mask = 32; + + RTFREE_LOCKED(rt); + } + } else { +#ifdef INET6 + bzero(&sin6, sizeof(sin6)); + sin6.sin6_len = sizeof(struct sockaddr_in6); + sin6.sin6_family = AF_INET6; + sin6.sin6_addr = fle->f.r.dst.r_dst6; + /* XXX fib works for AF_INET only */ + rt = rtalloc1_fib((struct sockaddr *)&sin6, 0, 0, 0); + if (rt != NULL) { + fle->f.fle_o_ifx = rt->rt_ifp->if_index; + + if (rt->rt_flags & RTF_GATEWAY && + rt->rt_gateway->sa_family == AF_INET6) + fle->f.n.next_hop6 = + ((struct sockaddr_in6 *)(rt->rt_gateway))->sin6_addr; + if (rt_mask(rt)) +/* + fle->f.dst_mask = bitcount32(((struct sockaddr_in6 *) + rt_mask(rt))->sin_addr.s_addr); + else if (rt->rt_flags & RTF_HOST) */ + /* Give up. We can't determine mask :( */ + fle->f.dst_mask = 128; + + RTFREE_LOCKED(rt); + } + + /* Do route lookup on source address, to fill in src_mask. */ + bzero(&sin6, sizeof(sin6)); + sin6.sin6_len = sizeof(struct sockaddr_in6); + sin6.sin6_family = AF_INET6; + sin6.sin6_addr = fle->f.r.src.r_src6; + /* XXX MRT 0 as a default revisit. need the mbuf for fib*/ + rt = rtalloc1_fib((struct sockaddr *)&sin6, 0, 0, 0); + if (rt != NULL) { +/* + if (rt_mask(rt)) + fle->f.src_mask = bitcount32(((struct sockaddr_in6 *) + rt_mask(rt))->sin_addr.s_addr); + else if (rt->rt_flags & RTF_HOST) */ + /* Give up. We can't determine mask :( */ + fle->f.src_mask = 128; + + RTFREE_LOCKED(rt); + } - RTFREE_LOCKED(rt); +#endif } /* Push new flow at the and of hash. */ @@ -347,6 +658,10 @@ mtx_init(&priv->export_mtx, "export dgram lock", NULL, MTX_DEF); + generate_v9_templates(priv); + + ng_netflow_switch_version(priv, priv->version, 1); + return (0); } @@ -359,6 +674,7 @@ item_p item = NULL; int i; + /* * We are going to free probably billable data. * Expire everything before freeing it. @@ -371,7 +687,7 @@ } if (item != NULL) - export_send(priv, item, NG_QUEUE); + (*record_send)(priv, item, NG_QUEUE); uma_zdestroy(priv->zone); @@ -383,46 +699,34 @@ if (priv->hash) free(priv->hash, M_NETFLOW_HASH); + /* FreeFlow Tables */ + for (i = 0; i < priv->flowsets_count; i++) + free(priv->v9_flowsets[i], M_NETFLOW_GENERAL); + mtx_destroy(&priv->export_mtx); } -/* Insert packet from into flow cache. */ +/* + * Insert packet from into flow cache. Assume size/version check passed + */ int -ng_netflow_flow_add(priv_p priv, struct ip *ip, unsigned int src_if_index) +ng_netflow_flow_add(priv_p priv, caddr_t ip_ptr, caddr_t upper_ptr, uint8_t upper_proto, uint8_t is_frag, unsigned int src_if_index) { register struct flow_entry *fle, *fle1; struct flow_hash_entry *hsh; struct flow_rec r; + struct ip *ip = NULL; +#ifdef INET6 + struct ip6_hdr *ip6 = NULL; +#endif item_p item = NULL; - int hlen, plen; + int plen; int error = 0; uint8_t tcp_flags = 0; - - /* Try to fill flow_rec r */ - bzero(&r, sizeof(r)); - /* check version */ - if (ip->ip_v != IPVERSION) - return (EINVAL); - - /* verify min header length */ - hlen = ip->ip_hl << 2; - - if (hlen < sizeof(struct ip)) - return (EINVAL); - - r.r_src = ip->ip_src; - r.r_dst = ip->ip_dst; - - /* save packet length */ - plen = ntohs(ip->ip_len); - - r.r_ip_p = ip->ip_p; - r.r_tos = ip->ip_tos; - - r.r_i_ifx = src_if_index; + uint16_t eproto; /* - * XXX NOTE: only first fragment of fragmented TCP, UDP and + * XXX Fragmentation NOTE: only first fragment of fragmented TCP, UDP and * ICMP packet will be recorded with proper s_port and d_port. * Following fragments will be recorded simply as IP packet with * ip_proto = ip->ip_p and s_port, d_port set to zero. @@ -430,22 +734,91 @@ * ip packet assebmling here. Anyway, (in)famous trafd works this way - * and nobody complains yet :) */ - if ((ip->ip_off & htons(IP_OFFMASK)) == 0) - switch(r.r_ip_p) { - case IPPROTO_TCP: - { - register struct tcphdr *tcp; - - tcp = (struct tcphdr *)((caddr_t )ip + hlen); - r.r_sport = tcp->th_sport; - r.r_dport = tcp->th_dport; - tcp_flags = tcp->th_flags; - break; + + /* Try to fill flow_rec r */ + bzero(&r, sizeof(r)); + ip = (struct ip *)ip_ptr; + if (ip->ip_v == IPVERSION) { + eproto = ETHERTYPE_IP; + r.src.r_src = ip->ip_src; + r.dst.r_dst = ip->ip_dst; + + /* Assume L$ template by default */ + r.flow_type = NETFLOW_V9_FLOW_V4_L4; + + /* save packet length */ + plen = ntohs(ip->ip_len); + + r.r_tos = ip->ip_tos; + + if (is_frag == 0) { + switch(upper_proto) { + case IPPROTO_TCP: + { + register struct tcphdr *tcp; + + tcp = (struct tcphdr *)upper_ptr; + r.r_ports = *(uint32_t *)upper_ptr; + tcp_flags = tcp->th_flags; + /* r.flow_type = NETFLOW_V9_FLOW_V4_L4; */ + break; + } + case IPPROTO_UDP: + case IPPROTO_SCTP: + { + r.r_ports = *(uint32_t *)upper_ptr; + /* r.flow_type = NETFLOW_V9_FLOW_V4_L4; */ + break; + } + + } } + + } else { +#ifdef INET6 + /* IPv6 traffic */ + ip = NULL; + ip6 = (struct ip6_hdr *)ip_ptr; + eproto = ETHERTYPE_IPV6; + + r.src.r_src6 = ip6->ip6_src; + r.dst.r_dst6 = ip6->ip6_dst; + + /* Assume L4 template by default */ + r.flow_type = NETFLOW_V9_FLOW_V6_L4; + + /* save packet length */ + plen = ntohs(ip6->ip6_plen) + sizeof(struct ip6_hdr); + + //r.r_tos = ip->ip_tos; + + if (is_frag == 0) { + switch(upper_proto) { + case IPPROTO_TCP: + { + register struct tcphdr *tcp; + + tcp = (struct tcphdr *)upper_ptr; + r.r_ports = *(uint32_t *)upper_ptr; + tcp_flags = tcp->th_flags; + /* r.flow_type = NETFLOW_V9_FLOW_V6_L4; */ + break; + } case IPPROTO_UDP: - r.r_ports = *(uint32_t *)((caddr_t )ip + hlen); - break; + case IPPROTO_SCTP: + { + r.r_ports = *(uint32_t *)upper_ptr; + /* r.flow_type = NETFLOW_V9_FLOW_V6_L4; */ + break; + } + + } } +#endif + } + + r.r_ip_p = upper_proto; + r.r_i_ifx = src_if_index; /* Update node statistics. XXX: race... */ priv->info.nfinfo_packets ++; @@ -486,7 +859,7 @@ * - it is going to overflow counter */ if (tcp_flags & TH_FIN || tcp_flags & TH_RST || AGED(fle) || - (fle->f.bytes >= (UINT_MAX - IF_MAXMTU)) ) { + (fle->f.bytes >= (cntr_max - IF_MAXMTU)) ) { TAILQ_REMOVE(&hsh->head, fle, fle_hash); expire_flow(priv, &item, fle, NG_QUEUE); atomic_add_32(&priv->info.nfinfo_act_exp, 1); @@ -502,7 +875,7 @@ } } } else /* A new flow entry. */ - error = hash_insert(priv, hsh, &r, plen, tcp_flags); + error = hash_insert(priv, hsh, &r, eproto, plen, tcp_flags); mtx_unlock(&hsh->mtx); @@ -611,6 +984,65 @@ return (error); } +/* We have full datagram in privdata. Send it to export hook. */ +static int +export_send_v9(priv_p priv, item_p item, int flags) +{ + struct mbuf *m = NGI_M(item); + struct netflow_v9_export_dgram *dgram = mtod(m, + struct netflow_v9_export_dgram *); + struct netflow_v9_header *header = &dgram->header; + struct timespec ts; + int error = 0; + uint16_t len = 0; + + struct netflow_v9_mbuf_tag *t; + struct netflow_v9_flowset_header *fs = NULL; + struct m_tag *mt = m_tag_locate(m, MTAG_NETFLOW, MTAG_NETFLOW_V9, NULL); + + if (mt == NULL) { + /* */ + log(LOG_DEBUG, "ng_netflow: V9 export packet without tag!\n"); + return (0); + } + + t = (struct netflow_v9_mbuf_tag *)(mt + 1); + + /* Close FlowSet if not closed */ + if (t->length != t->flow_header) { + fs = (struct netflow_v9_flowset_header *)(mtod(m, char *) + t->flow_header); + len = (uint16_t)(t->length - t->flow_header); + if (len % 4) { + t->length += 4 - (len % 4); + len += 4 - (len % 4); + } + fs->length = htons(len); + } + + + + /* Fill mbuf header. */ + m->m_len = m->m_pkthdr.len = t->length; + + /* Fill export header. */ + header->count = t->count; + header->sys_uptime = htonl(MILLIUPTIME(time_uptime)); + getnanotime(&ts); + header->unix_secs = htonl(ts.tv_sec); + header->seq_num = htonl(atomic_fetchadd_32(&priv->flow_seq, 1)); + header->count = htons(t->count); + header->source_id = htonl(NG_NODE_ID(priv->node)); + + /* remove tag */ + m_tag_delete_chain(m, NULL); + + if (priv->export != NULL) + NG_FWD_ITEM_HOOK_FLAGS(error, item, priv->export, flags); + else + NG_FREE_ITEM(item); + + return (error); +} /* Add export record to dgram. */ static int @@ -628,9 +1060,9 @@ ("ng_netflow: export too big")); /* Fill in export record. */ - rec->src_addr = fle->f.r.r_src.s_addr; - rec->dst_addr = fle->f.r.r_dst.s_addr; - rec->next_hop = fle->f.next_hop.s_addr; + rec->src_addr = fle->f.r.src.r_src.s_addr; + rec->dst_addr = fle->f.r.dst.r_dst.s_addr; + rec->next_hop = fle->f.n.next_hop.s_addr; rec->i_ifx = htons(fle->f.fle_i_ifx); rec->o_ifx = htons(fle->f.fle_o_ifx); rec->packets = htonl(fle->f.packets); @@ -654,6 +1086,135 @@ return (0); } +/* Add V9 record to dgram. */ +static int +export_add_v9(item_p item, struct flow_entry *fle) +{ + size_t len = 0; + uint16_t new_flow = 0; + void *offset_ptr; + struct netflow_v9_mbuf_tag *t; + struct netflow_v9_flowset_header *fs = NULL; + struct mbuf *m = NGI_M(item); + struct m_tag *mt = m_tag_locate(m, MTAG_NETFLOW, MTAG_NETFLOW_V9, NULL); + + if (mt == NULL) { + /* */ + log(LOG_DEBUG, "ng_netflow: V9 export packet without tag!\n"); + return (0); + } + + t = (struct netflow_v9_mbuf_tag *)(mt + 1); + offset_ptr = (mtod(m, char *) + t->length); + + /* Check if new records has the same template */ + if (fle->f.r.flow_type != t->flow_type) { + new_flow = 1; + + /* 'Close' old FlowSet */ + fs = (struct netflow_v9_flowset_header *)(mtod(m, char *) + t->flow_header); + len = (uint16_t)(t->length - t->flow_header); + if (len % 4) { + t->length += 4 - (len % 4); + len += 4 - (len % 4); + } + fs->length = htons(len); + + /* Prepare 'new', but do not modify any counters here because switch can fail */ + t->flow_type = NETFLOW_V9_FLOW_FAKE; + t->flow_header = t->length; + fs = (struct netflow_v9_flowset_header *)(mtod(m, char *) + t->length); + offset_ptr = (fs + 1); + } + + + switch (fle->f.r.flow_type) { + case NETFLOW_V9_FLOW_V4_L4: + { + /* IPv4 TCP/UDP/[SCTP] */ + struct netflow_v9_record_ipv4_tcp *rec = (struct netflow_v9_record_ipv4_tcp *)offset_ptr; + + + rec->src_addr = fle->f.r.src.r_src.s_addr; + rec->dst_addr = fle->f.r.dst.r_dst.s_addr; + rec->next_hop = fle->f.n.next_hop.s_addr; + rec->i_ifx = htons(fle->f.fle_i_ifx); + rec->o_ifx = htons(fle->f.fle_o_ifx); + rec->i_packets = htonl(fle->f.packets); + rec->i_octets = htonl(fle->f.bytes); + rec->o_packets = htonl(0); + rec->o_octets = htonl(0); + rec->first = htonl(MILLIUPTIME(fle->f.first)); + rec->last = htonl(MILLIUPTIME(fle->f.last)); + rec->s_port = fle->f.r.r_sport; + rec->d_port = fle->f.r.r_dport; + rec->flags = fle->f.tcp_flags; + rec->prot = fle->f.r.r_ip_p; + rec->tos = fle->f.r.r_tos; + rec->dst_mask = fle->f.dst_mask; + rec->src_mask = fle->f.src_mask; + + /* Not supported fields. */ + rec->src_as = rec->dst_as = 0; + + len = sizeof(struct netflow_v9_record_ipv4_tcp); + break; + } +#ifdef INET6 + case NETFLOW_V9_FLOW_V6_L4: + { + /* IPv6 TCP/UDP/[SCTP] */ + struct netflow_v9_record_ipv6_tcp *rec = (struct netflow_v9_record_ipv6_tcp *)offset_ptr; + + /* ACHTUNG! unchecked code! */ + rec->src_addr = fle->f.r.src.r_src6; + rec->dst_addr = fle->f.r.dst.r_dst6; + rec->next_hop = fle->f.n.next_hop6; + rec->i_ifx = htons(fle->f.fle_i_ifx); + rec->o_ifx = htons(fle->f.fle_o_ifx); + rec->i_packets = htonl(fle->f.packets); + rec->i_octets = htonl(fle->f.bytes); + rec->first = htonl(MILLIUPTIME(fle->f.first)); + rec->last = htonl(MILLIUPTIME(fle->f.last)); + rec->s_port = fle->f.r.r_sport; + rec->d_port = fle->f.r.r_dport; + rec->flags = fle->f.tcp_flags; + rec->prot = fle->f.r.r_ip_p; + rec->tos = fle->f.r.r_tos; + rec->dst_mask = fle->f.dst_mask; + rec->src_mask = fle->f.src_mask; + + /* Not supported fields. */ + rec->src_as = rec->dst_as = 0; + + len = sizeof(struct netflow_v9_record_ipv6_tcp); + break; + } +#endif + default: + { + log(LOG_DEBUG, "ng_netflow: Don't know what to do with %d flow type!\n", fle->f.r.flow_type); + return (0); + } + } + + if (new_flow) { + /* Generate data segment ID */ + fs->id = htons(0x100 + fle->f.r.flow_type); + t->flow_type = fle->f.r.flow_type; + t->length += sizeof(struct netflow_v9_flowset_header); + } + + t->length += len; + t->count++; + + if (t->length + NETFLOW_V9_MAX_RECORD_SIZE + 4 >= _NETFLOW_V9_MAX_SIZE(t->mtu)) + return (1); /* end of datagram */ + else + return (0); +} + + /* Periodic flow expiry run. */ void ng_netflow_expire(void *arg) diff -urN sys/netgraph/_netflow.orig/netflow.h sys/netgraph/netflow/netflow.h --- sys/netgraph/_netflow.orig/netflow.h 2009-09-01 02:37:44.000000000 +0400 +++ sys/netgraph/netflow/netflow.h 2009-09-06 12:41:29.000000000 +0400 @@ -46,6 +46,7 @@ #define NETFLOW_V1 1 #define NETFLOW_V5 5 +#define NETFLOW_V9 9 struct netflow_v1_header { @@ -69,6 +70,16 @@ uint16_t pad; /* Pad to word boundary */ } __attribute__((__packed__)); +struct netflow_v9_header +{ + uint16_t version; /* NetFlow version */ + uint16_t count; /* Total number of records in packet */ + uint32_t sys_uptime; /* System uptime */ + uint32_t unix_secs; /* Current seconds since 0000 UTC 1970 */ + uint32_t seq_num; /* Sequence number */ + uint32_t source_id; /* Observation Domain id */ +} __attribute__((__packed__)); + struct netflow_v1_record { uint32_t src_addr; /* Source IP address */ @@ -115,6 +126,142 @@ uint16_t pad2; /* Pad to word boundary */ } __attribute__((__packed__)); + + +/* RFC3954 field definitions */ +#define NETFLOW_V9_FIELD_IN_BYTES 1 /* Input bytes count for a flow. Default 4, can be 8 */ +#define NETFLOW_V9_FIELD_IN_PKTS 2 /* Incoming counter with number of packets associated with an IP Flow. Default 4 */ +#define NETFLOW_V9_FIELD_FLOWS 3 /* Number of Flows that were aggregated. Default 4 */ +#define NETFLOW_V9_FIELD_PROTOCOL 4 /* IP protocol byte. 1 */ +#define NETFLOW_V9_FIELD_TOS 5 /* Type of service byte setting when entering the incoming interface. 1 */ +#define NETFLOW_V9_FIELD_TCP_FLAGS 6 /* TCP flags; cumulative of all the TCP flags seen in this Flow. 1 */ +#define NETFLOW_V9_FIELD_L4_SRC_PORT 7 /* TCP/UDP source port number. 2 */ +#define NETFLOW_V9_FIELD_IPV4_SRC_ADDR 8 /* IPv4 source address. 4 */ +#define NETFLOW_V9_FIELD_SRC_MASK 9 /* The number of contiguous bits in the source subnet mask (i.e., the mask in slash notation). 1 */ +#define NETFLOW_V9_FIELD_INPUT_SNMP 10 /* Input interface index. Default 2 */ +#define NETFLOW_V9_FIELD_L4_DST_PORT 11 /* TCP/UDP destination port number. 2 */ +#define NETFLOW_V9_FIELD_IPV4_DST_ADDR 12 /* IPv4 destination address. 4 */ +#define NETFLOW_V9_FIELD_DST_MASK 13 /* The number of contiguous bits in the destination subnet mask (i.e., the mask in slash notation). 1 */ +#define NETFLOW_V9_FIELD_OUTPUT_SNMP 14 /* Output interface index. Default 2 */ +#define NETFLOW_V9_FIELD_IPV4_NEXT_HOP 15 /* IPv4 address of the next-hop router. 4 */ +#define NETFLOW_V9_FIELD_SRC_AS 16 /* Source BGP autonomous system number. Default 2, can be 4 */ +#define NETFLOW_V9_FIELD_DST_AS 17 /* Destination BGP autonomous system number. Default 2, can be 4 */ +#define NETFLOW_V9_FIELD_BGP_IPV4_NEXT_HOP 18 /* Next-hop router's IP address in the BGP domain. 4 */ +#define NETFLOW_V9_FIELD_MUL_DST_PKTS 19 /* IP multicast outgoing packet counter for packets associated with IP flow. Default 4 */ +#define NETFLOW_V9_FIELD_MUL_DST_BYTES 20 /* IP multicast outgoing Octet (byte) counter for the number of bytes associated with IP flow. Default 4 */ +#define NETFLOW_V9_FIELD_LAST_SWITCHED 21 /* sysUptime in msec at which the last packet of this Flow was switched. 4 */ +#define NETFLOW_V9_FIELD_FIRST_SWITCHED 22 /* sysUptime in msec at which the first packet of this Flow was switched. 4 */ +#define NETFLOW_V9_FIELD_OUT_BYTES 23 /* Outgoing counter for the number of bytes associated with an IP Flow. Default 4 */ +#define NETFLOW_V9_FIELD_OUT_PKTS 24 /* Outgoing counter for the number of packets associated with an IP Flow. Default 4 */ +#define NETFLOW_V9_FIELD_IPV6_SRC_ADDR 27 /* IPv6 source address. 16 */ +#define NETFLOW_V9_FIELD_IPV6_DST_ADDR 28 /* IPv6 destination address. 16 */ +#define NETFLOW_V9_FIELD_IPV6_SRC_MASK 29 /* Length of the IPv6 source mask in contiguous bits. 1 */ +#define NETFLOW_V9_FIELD_IPV6_DST_MASK 30 /* Length of the IPv6 destination mask in contiguous bits. 1 */ +#define NETFLOW_V9_FIELD_IPV6_FLOW_LABEL 31 /* IPv6 flow label as per RFC 2460 definition. 3 */ +#define NETFLOW_V9_FIELD_ICMP_TYPE 32 /* Internet Control Message Protocol (ICMP) packet type; reported as ICMP Type * 256 + ICMP code. 2 */ +#define NETFLOW_V9_FIELD_MUL_IGMP_TYPE 33 /* Internet Group Management Protocol (IGMP) packet type. 1 */ +#define NETFLOW_V9_FIELD_SAMPLING_INTERVAL 34 /* When using sampled NetFlow, the rate at which packets are sampled; for example, a value of 100 indicates that one of every hundred packets is sampled. 4 */ +#define NETFLOW_V9_FIELD_SAMPLING_ALGORITHM 35 /* For sampled NetFlow platform-wide: 0x01 deterministic sampling 0x02 random sampling. 1 */ +#define NETFLOW_V9_FIELD_FLOW_ACTIVE_TIMEOUT 36 /* Timeout value (in seconds) for active flow entries in the NetFlow cache. 2 */ +#define NETFLOW_V9_FIELD_FLOW_INACTIVE_TIMEOUT 37 /* Timeout value (in seconds) for inactive Flow entries in the NetFlow cache. 2 */ +#define NETFLOW_V9_FIELD_ENGINE_TYPE 38 /* Type of Flow switching engine (route processor, linecard, etc...). 1 */ +#define NETFLOW_V9_FIELD_ENGINE_ID 39 /* ID number of the Flow switching engine. 1 */ +#define NETFLOW_V9_FIELD_TOTAL_BYTES_EXP 40 /* Counter with for the number of bytes exported by the Observation Domain. Default 4 */ +#define NETFLOW_V9_FIELD_TOTAL_PKTS_EXP 41 /* Counter with for the number of packets exported by the Observation Domain. Default 4 */ +#define NETFLOW_V9_FIELD_TOTAL_FLOWS_EXP 42 /* Counter with for the number of flows exported by the Observation Domain. Default 4 */ +#define NETFLOW_V9_FIELD_MPLS_TOP_LABEL_TYPE 46 /* MPLS Top Label Type. 1 */ +#define NETFLOW_V9_FIELD_MPLS_TOP_LABEL_IP_ADDR 47 /* Forwarding Equivalent Class corresponding to the MPLS Top Label. 4 */ +#define NETFLOW_V9_FIELD_FLOW_SAMPLER_ID 48 /* Identifier shown in "show flow-sampler". 1 */ +#define NETFLOW_V9_FIELD_FLOW_SAMPLER_MODE 49 /* The type of algorithm used for sampling data. 2 */ +#define NETFLOW_V9_FIELD_FLOW_SAMPLER_RANDOM_INTERVAL 50 /* Packet interval at which to sample. 4. */ +#define NETFLOW_V9_FIELD_DST_TOS 55 /* Type of Service byte setting when exiting outgoing interface. 1. */ +#define NETFLOW_V9_FIELD_SRC_MAC 56 /* Source MAC Address. 6 */ +#define NETFLOW_V9_FIELD_DST_MAC 57 /* Destination MAC Address. 6 */ +#define NETFLOW_V9_FIELD_SRC_VLAN 58 /* Virtual LAN identifier associated with ingress interface. 2 */ +#define NETFLOW_V9_FIELD_DST_VLAN 59 /* irtual LAN identifier associated with egress interface. 2 */ +#define NETFLOW_V9_FIELD_IP_PROTOCOL_VERSION 60 /* Internet Protocol Version. Set to 4 for IPv4, set to 6 for IPv6. If not present in the template, then version 4 is assumed. 1. */ +#define NETFLOW_V9_FIELD_DIRECTION 61 /* Flow direction: 0 - ingress flow 1 - egress flow. 1 */ +#define NETFLOW_V9_FIELD_IPV6_NEXT_HOP 62 /* IPv6 address of the next-hop router. 16 */ +#define NETFLOW_V9_FIELD_BGP_IPV6_NEXT_HOP 63 /* Next-hop router in the BGP domain. 16 */ +#define NETFLOW_V9_FIELD_IPV6_OPTION_HEADERS 64 /* Bit-encoded field identifying IPv6 option headers found in the flow */ +#define NETFLOW_V9_FIELD_MPLS_LABEL_1 70 /* MPLS label at position 1 in the stack. 3 */ +#define NETFLOW_V9_FIELD_MPLS_LABEL_2 71 /* MPLS label at position 2 in the stack. 3 */ +#define NETFLOW_V9_FIELD_MPLS_LABEL_3 72 /* MPLS label at position 3 in the stack. 3 */ +#define NETFLOW_V9_FIELD_MPLS_LABEL_4 73 /* MPLS label at position 4 in the stack. 3 */ +#define NETFLOW_V9_FIELD_MPLS_LABEL_5 74 /* MPLS label at position 5 in the stack. 3 */ +#define NETFLOW_V9_FIELD_MPLS_LABEL_6 75 /* MPLS label at position 6 in the stack. 3 */ +#define NETFLOW_V9_FIELD_MPLS_LABEL_7 76 /* MPLS label at position 7 in the stack. 3 */ +#define NETFLOW_V9_FIELD_MPLS_LABEL_8 77 /* MPLS label at position 8 in the stack. 3 */ +#define NETFLOW_V9_FIELD_MPLS_LABEL_9 78 /* MPLS label at position 9 in the stack. 3 */ +#define NETFLOW_V9_FIELD_MPLS_LABEL_10 79 /* MPLS label at position 10 in the stack. 3 */ + +#ifdef COUNTERS_64 +#define cntr uint64_t +#define cntr_max UINT64_MAX +#else +#define cntr uint32_t +#define cntr_max UINT_MAX +#endif + +struct netflow_v9_template +{ + int field_id; + int field_length; +}; + +/* Template ID for tcp/udp v4 streams ID:257 (0x100 + NETFLOW_V9_FLOW_V4_L4) */ +struct netflow_v9_record_ipv4_tcp +{ + uint32_t src_addr; /* Source IPv4 address (IPV4_SRC_ADDR) */ + uint32_t dst_addr; /* Destination IPv4 address (IPV4_DST_ADDR) */ + uint32_t next_hop; /* Next hop IPv4 address (IPV4_NEXT_HOP) */ + uint16_t i_ifx; /* Source interface index (INPUT_SNMP) */ + uint16_t o_ifx; /* Destination interface index (OUTPUT_SNMP) */ + cntr i_packets; /* Number of incoming packets in a flow (IN_PKTS) */ + cntr i_octets; /* Number of incoming octets in a flow (IN_BYTES) */ + cntr o_packets; /* Number of outgoing packets in a flow (OUT_PKTS) */ + cntr o_octets; /* Number of outgoing octets in a flow (OUT_BYTES) */ + uint32_t first; /* System uptime at start of a flow (FIRST_SWITCHED) */ + uint32_t last; /* System uptime at end of a flow (LAST_SWITCHED) */ + uint16_t s_port; /* Source port (L4_SRC_PORT) */ + uint16_t d_port; /* Destination port (L4_DST_PORT) */ + uint8_t flags; /* Cumulative OR of tcp flags (TCP_FLAGS) */ + uint8_t prot; /* IP protocol */ + uint8_t tos; /* IP type of service IN (or OUT) (TOS) */ + uint32_t src_as; /* Src peer/origin Autonomous System (SRC_AS) */ + uint32_t dst_as; /* Dst peer/origin Autonomous System (DST_AS) */ + uint8_t src_mask; /* Source route's mask bits (SRC_MASK) */ + uint8_t dst_mask; /* Destination route's mask bits (DST_MASK) */ +} __attribute__((__packed__)); + + +/* Template ID for tcp/udp v6 streams ID: 260 (0x100 + NETFLOW_V9_FLOW_V6_L4) */ +struct netflow_v9_record_ipv6_tcp +{ + struct in6_addr src_addr; /* Source IPv6 address (IPV6_SRC_ADDR) */ + struct in6_addr dst_addr; /* Destination IPv6 address (IPV6_DST_ADDR) */ + struct in6_addr next_hop; /* Next hop IPv6 address (IPV6_NEXT_HOP) */ + uint16_t i_ifx; /* Source interface index (INPUT_SNMP) */ + uint16_t o_ifx; /* Destination interface index (OUTPUT_SNMP) */ + cntr i_packets; /* Number of incoming packets in a flow (IN_PKTS) */ + cntr i_octets; /* Number of incoming octets in a flow (IN_BYTES) */ + cntr o_packets; /* Number of outgoing packets in a flow (OUT_PKTS) */ + cntr o_octets; /* Number of outgoing octets in a flow (OUT_BYTES) */ + uint32_t first; /* System uptime at start of a flow (FIRST_SWITCHED) */ + uint32_t last; /* System uptime at end of a flow (LAST_SWITCHED) */ + uint16_t s_port; /* Source port (L4_SRC_PORT) */ + uint16_t d_port; /* Destination port (L4_DST_PORT) */ + uint8_t flags; /* Cumulative OR of tcp flags (TCP_FLAGS) */ + uint8_t prot; /* IP protocol */ + uint8_t tos; /* IP type of service IN (or OUT) (TOS) */ + uint32_t src_as; /* Src peer/origin Autonomous System (SRC_AS) */ + uint32_t dst_as; /* Dst peer/origin Autonomous System (DST_AS) */ + uint8_t src_mask; /* Source route's mask bits (SRC_MASK) */ + uint8_t dst_mask; /* Destination route's mask bits (DST_MASK) */ +} __attribute__((__packed__)); + +#define vlog(x, ...) log(LOG_DEBUG, "%s:%d " x "\n", __FUNCTION__, __LINE__, ##__VA_ARGS__) + #define NETFLOW_V1_MAX_RECORDS 24 #define NETFLOW_V5_MAX_RECORDS 30 @@ -123,7 +270,50 @@ #define NETFLOW_V5_MAX_SIZE (sizeof(netflow_v5_header)+ \ sizeof(netflow_v5_record)*NETFLOW_V5_MAX_RECORDS) +#define BASE_MTU 1500 +#define MIN_MTU sizeof(struct netflow_v5_header) +#define MAX_MTU 16384 +#define NETFLOW_V9_MAX_SIZE _NETFLOW_V9_MAX_SIZE(BASE_MTU) +#define _NETFLOW_V9_MAX_SIZE(x) (x) - sizeof(struct ip6_hdr) - sizeof(struct udphdr) +#define NETFLOW_V9_MAX_FLOWSETS 2 + +#define NETFLOW_V9_MAX_RECORD_SIZE sizeof(struct netflow_v9_record_ipv6_tcp) +#define NETFLOW_V9_MAX_PACKETS_TEMPL 500 /* Send data templates every ... packets */ +#define NETFLOW_V9_MAX_TIME_TEMPL 600 /* Send data templates every ... seconds */ +#define NETFLOW_V9_MAX_TEMPLATES 16 /* Not a real value */ +#define _NETFLOW_V9_TEMPLATE_SIZE(x) (sizeof(x) / sizeof(struct netflow_v9_template)) * 4 +//#define _NETFLOW_V9_TEMPLATE_SIZE(x) ((x) + 1) * 4 + +/* Flow Templates */ +#define NETFLOW_V9_FLOW_V4_L4 1 /* IPv4 TCP/UDP packet */ +#define NETFLOW_V9_FLOW_V4_ICMP 2 /* IPv4 ICMP packet, currently unused */ +#define NETFLOW_V9_FLOW_V4_L3 3 /* IPv4 IP packet */ +#define NETFLOW_V9_FLOW_V6_L4 4 /* IPv6 TCP/UDP packet */ +#define NETFLOW_V9_FLOW_V6_ICMP 5 /* IPv6 ICMP packet, currently unused */ +#define NETFLOW_V9_FLOW_V6_L3 6 /* IPv6 IP packet */ + +#define NETFLOW_V9_FLOW_FAKE 65535 /* Not uset used in real flowsets! */ + struct netflow_v5_export_dgram { struct netflow_v5_header header; struct netflow_v5_record r[NETFLOW_V5_MAX_RECORDS]; } __attribute__((__packed__)); + +struct netflow_v9_export_dgram { + struct netflow_v9_header header; + char data; /* MTU can change, record length is dynamic */ +}; + +struct netflow_v9_flowset_header { + uint16_t id; /* FlowSet id */ + uint16_t length; /* FlowSet length */ +} __attribute__((__packed__)); + +struct netflow_v9_mbuf_tag { + struct m_tag tag; /* pointer to mbuf tag */ + uint16_t length; /* Current packet length */ + uint16_t count; /* current records count */ + uint16_t mtu; /* max MTU shapshot */ + uint16_t flow_type; /* current flowset */ + uint16_t flow_header; /* offset pointing to current flow header */ +}; diff -urN sys/netgraph/_netflow.orig/ng_netflow.c sys/netgraph/netflow/ng_netflow.c --- sys/netgraph/_netflow.orig/ng_netflow.c 2009-09-01 02:37:44.000000000 +0400 +++ sys/netgraph/netflow/ng_netflow.c 2009-09-06 16:36:08.000000000 +0400 @@ -30,6 +30,8 @@ static const char rcs_id[] = "@(#) $FreeBSD: src/sys/netgraph/netflow/ng_netflow.c,v 1.20 2009/05/13 02:26:34 mav Exp $"; +#include "opt_inet6.h" + #include #include #include @@ -48,8 +50,11 @@ #include #include #include +#include +#include #include #include +#include #include #include @@ -114,6 +119,30 @@ &ng_netflow_setconfig_type_fields }; +/* Parse type for ng_netflow_setversion */ +static const struct ng_parse_struct_field ng_netflow_setversion_type_fields[] + = NG_NETFLOW_SETVERSION_TYPE; +static const struct ng_parse_type ng_netflow_setversion_type = { + &ng_parse_struct_type, + &ng_netflow_setversion_type_fields +}; + +/* Parse type for ng_netflow_settemplateperiodic */ +static const struct ng_parse_struct_field ng_netflow_settemplateperiodic_type_fields[] + = NG_NETFLOW_SETTEMPLATEPERIODIC_TYPE; +static const struct ng_parse_type ng_netflow_settemplateperiodic_type = { + &ng_parse_struct_type, + &ng_netflow_settemplateperiodic_type_fields +}; + +/* Parse type for ng_netflow_setmtu */ +static const struct ng_parse_struct_field ng_netflow_setmtu_type_fields[] + = NG_NETFLOW_SETMTU_TYPE; +static const struct ng_parse_type ng_netflow_setmtu_type = { + &ng_parse_struct_type, + &ng_netflow_setmtu_type_fields +}; + /* List of commands and how to convert arguments to/from ASCII */ static const struct ng_cmdlist ng_netflow_cmds[] = { { @@ -158,6 +187,27 @@ &ng_netflow_setconfig_type, NULL }, + { + NGM_NETFLOW_COOKIE, + NGM_NETFLOW_SETVERSION, + "setversion", + &ng_netflow_setversion_type, + NULL + }, + { + NGM_NETFLOW_COOKIE, + NGM_NETFLOW_SETTEMPLATEPERIODIC, + "settemplateperiodic", + &ng_netflow_settemplateperiodic_type, + NULL + }, + { + NGM_NETFLOW_COOKIE, + NGM_NETFLOW_SETMTU, + "setmtu", + &ng_netflow_setmtu_type, + NULL + }, { 0 } }; @@ -202,6 +252,13 @@ for (i = 0; i < NG_NETFLOW_MAXIFACES; i++) priv->ifaces[i].info.conf = NG_NETFLOW_CONF_INGRESS; + /* Set v9 defaults */ + priv->version = NETFLOW_V9; + priv->templ_time = NETFLOW_V9_MAX_TIME_TEMPL; + priv->templ_packets = NETFLOW_V9_MAX_PACKETS_TEMPL; + priv->mtu = BASE_MTU; + priv->flow_seq = 0; + /* Initialize callout handle */ callout_init(&priv->exp_callout, CALLOUT_MPSAFE); @@ -434,6 +491,52 @@ break; } + case NGM_NETFLOW_SETVERSION: + { + struct ng_netflow_setversion *set; + + if (msg->header.arglen != sizeof(struct ng_netflow_setversion)) + ERROUT(EINVAL); + + set = (struct ng_netflow_setversion *)msg->data; + if ((set->version != NETFLOW_V9) && (set->version != NETFLOW_V5)) + ERROUT(EINVAL); + + ng_netflow_switch_version(priv, set->version, 0); + + break; + } + case NGM_NETFLOW_SETTEMPLATEPERIODIC: + { + struct ng_netflow_settemplateperiodic *set; + + if (msg->header.arglen != sizeof(struct ng_netflow_settemplateperiodic)) + ERROUT(EINVAL); + + set = (struct ng_netflow_settemplateperiodic *)msg->data; + + /* XXX: Set atomic here */ + priv->templ_packets = set->packets; + priv->templ_time = set->time; + + break; + } + case NGM_NETFLOW_SETMTU: + { + struct ng_netflow_setmtu *set; + + if (msg->header.arglen != sizeof(struct ng_netflow_setmtu)) + ERROUT(EINVAL); + + set = (struct ng_netflow_setmtu *)msg->data; + if ((set->mtu < MIN_MTU) || (set->mtu > MAX_MTU)) + ERROUT(EINVAL); + + /* XXX: Set atomic here */ + priv->mtu = set->mtu; + + break; + } case NGM_NETFLOW_SHOW: { uint32_t *last; @@ -481,12 +584,15 @@ const priv_p priv = NG_NODE_PRIVATE(node); const iface_p iface = NG_HOOK_PRIVATE(hook); hook_p out; - struct mbuf *m = NULL; - struct ip *ip; + struct mbuf *m, *m_old = NULL; + struct ip *ip = NULL; + struct ip6_hdr *ip6 = NULL; struct m_tag *mtag; - int pullup_len = 0; + int pullup_len = 0, off; + uint8_t upper_proto = 0, is_frag = 0; int error = 0, bypass = 0; unsigned int src_if_index; + caddr_t upper_ptr = NULL; if (hook == priv->export) { /* @@ -541,6 +647,7 @@ } NGI_GET_M(item, m); + m_old = m; /* Increase counters. */ iface->info.ifinfo_packets++; @@ -569,6 +676,22 @@ } \ } while (0) +/* +#define M_HCHECK(length) do { \ + pullup_len += length + sizeof(ip6_ext); \ + if ((m)->m_pkthdr.len < (pullup_len)) { \ + pullup_len -= length + sizeof(ip6_ext); + M_CHECK(length); + ` + } \ + if ((m)->m_len < (pullup_len) && \ + (((m) = m_pullup((m),(pullup_len))) == NULL)) { \ + error = ENOBUFS; \ + goto done; \ + } \ +} while (0) +*/ + switch (iface->info.ifinfo_dlt) { case DLT_EN10MB: /* Ethernet */ { @@ -586,6 +709,33 @@ eh = mtod(m, struct ether_header *); ip = (struct ip *)(eh + 1); break; +#ifdef INET6 + case ETHERTYPE_IPV6: + /* + * This is done not to pullup mbuf twice on every ext + * header + */ + pullup_len += sizeof(struct ip6_hdr) + sizeof(struct ip6_ext); + if (m->m_pkthdr.len >= pullup_len) { + if ((m = m_pullup(m, pullup_len)) == NULL) { + error = ENOBUFS; + goto done; + } + pullup_len -= sizeof(struct ip6_ext); + } else { + pullup_len -= sizeof(struct ip6_hdr) + sizeof(struct ip6_ext); + M_CHECK(sizeof(struct ip6_hdr)); + eh = mtod(m, struct ether_header *); + ip6 = (struct ip6_hdr *)(eh + 1); + if (ip6->ip6_nxt != IPPROTO_NONE) { + error = EINVAL; + goto bypass; + } + } + eh = mtod(m, struct ether_header *); + ip6 = (struct ip6_hdr *)(eh + 1); + break; +#endif case ETHERTYPE_VLAN: { struct ether_vlan_header *evh; @@ -597,6 +747,29 @@ M_CHECK(sizeof(struct ip)); ip = (struct ip *)(evh + 1); break; + } else if (ntohs(evh->evl_proto) == ETHERTYPE_IPV6) { +#ifdef INET6 + pullup_len += sizeof(struct ip6_hdr) + sizeof(struct ip6_ext); + if (m->m_pkthdr.len >= pullup_len) { + if ((m = m_pullup(m, pullup_len)) == NULL) { + error = ENOBUFS; + goto done; + } + pullup_len -= sizeof(struct ip6_ext); + } else { + pullup_len -= sizeof(struct ip6_hdr) + sizeof(struct ip6_ext); + M_CHECK(sizeof(struct ip6_hdr)); + eh = mtod(m, struct ether_header *); + ip6 = (struct ip6_hdr *)(eh + 1); + if (ip6->ip6_nxt != IPPROTO_NONE) { + error = EINVAL; + goto bypass; + } + } + eh = mtod(m, struct ether_header *); + ip6 = (struct ip6_hdr *)(eh + 1); + break; +#endif } } default: @@ -607,18 +780,32 @@ case DLT_RAW: /* IP packets */ M_CHECK(sizeof(struct ip)); ip = mtod(m, struct ip *); +#ifdef INET6 + if (ip->ip_v == 6) { + /* IPv6 packet */ + ip = NULL; + M_CHECK(sizeof(struct ip6_hdr)); + ip6 = mtod(m, struct ip6_hdr *); + } +#endif break; default: goto bypass; break; } - if ((ip->ip_off & htons(IP_OFFMASK)) == 0) { + if ((ip != NULL) && ((ip->ip_off & htons(IP_OFFMASK)) == 0)) { + if ((ip->ip_v != IPVERSION) || + ((ip->ip_hl << 2) < sizeof(struct ip))) + goto bypass; /* - * In case of IP header with options, we haven't pulled + * In case of IPv4 header with options, we haven't pulled * up enough, yet. */ pullup_len += (ip->ip_hl << 2) - sizeof(struct ip); + off = pullup_len; + //vlog("upper_offset = %d", off); + upper_proto = ip->ip_p; switch (ip->ip_p) { case IPPROTO_TCP: @@ -627,38 +814,161 @@ case IPPROTO_UDP: M_CHECK(sizeof(struct udphdr)); break; + case IPPROTO_SCTP: + M_CHECK(sizeof(struct sctphdr)); + break; } - } + } else if (ip != NULL) { + is_frag = 1; + upper_proto = ip->ip_p; + if ((ip->ip_v != IPVERSION) || + ((ip->ip_hl << 2) < sizeof(struct ip))) + goto bypass; + } else if (ip6 != NULL) { +#ifdef INET6 + /* Check if we can export */ + if (priv->version < NETFLOW_V9) + goto bypass; + + /* Loop thru IPv6 extended headers to get upper layer header / frag */ + int cur = ip6->ip6_nxt, hdr_off = 0; + struct ip6_ext *ip6e; + struct ip6_frag *ip6f; + + off = pullup_len; + upper_proto = cur; + + if ((ip6->ip6_vfc & IPV6_VERSION_MASK) != IPV6_VERSION) + goto bypass; + + while (42) { + + /* + * At the moment we're 'standing' with pullup_len and + * off + */ + switch (cur) { + + /* Ensure pointer is contiguous */ + case IPPROTO_TCP: + M_CHECK(sizeof(struct tcphdr)); + goto loopend; + case IPPROTO_UDP: + M_CHECK(sizeof(struct udphdr)); + goto loopend; + case IPPROTO_SCTP: + M_CHECK(sizeof(struct sctphdr)); + goto loopend; + + /* Loop until 'real' upper layer headers */ + case IPPROTO_HOPOPTS: + case IPPROTO_ROUTING: + case IPPROTO_DSTOPTS: + ip6e = (struct ip6_ext *)(mtod(m, caddr_t) + off); + upper_proto = ip6e->ip6e_nxt; + hdr_off = (ip6e->ip6e_len + 1) << 3; + break; - switch (iface->info.ifinfo_dlt) { - case DLT_EN10MB: - { - struct ether_header *eh; + /* RFC4302, can be before DSTOPTS */ + case IPPROTO_AH: + ip6e = (struct ip6_ext *)(mtod(m, caddr_t) + off); + upper_proto = ip6e->ip6e_nxt; + hdr_off = (ip6e->ip6e_len + 2) << 2; + break; - eh = mtod(m, struct ether_header *); - switch (ntohs(eh->ether_type)) { - case ETHERTYPE_IP: - ip = (struct ip *)(eh + 1); - break; - case ETHERTYPE_VLAN: - { - struct ether_vlan_header *evh; + + case IPPROTO_FRAGMENT: + ip6f = (struct ip6_frag *)(mtod(m, caddr_t) + off); + upper_proto = ip6f->ip6f_nxt; + hdr_off = sizeof(struct ip6_frag); + off += hdr_off; + is_frag = 1; + goto loopend; + +/* + case IPPROTO_NONE: + goto loopend; +*/ + default: + goto loopend; + } - evh = mtod(m, struct ether_vlan_header *); - ip = (struct ip *)(evh + 1); + off += hdr_off + sizeof(struct ip6_ext); + cur = upper_proto; + if (m->m_pkthdr.len >= off) { + if ((m = m_pullup(m, off)) == NULL) { + error = ENOBUFS; + goto done; + } + off -= sizeof(struct ip6_ext); + pullup_len += hdr_off; + } else { + /* + * Packet ends somewhere here. + * if its next header is not IPPROTO_NONE it is + * possibly mailformed packet. Let's count as RAW IP + */ + upper_proto = IPPROTO_NONE; + off -= sizeof(struct ip6_ext); + goto loopend; + } + + } +#endif + } + +#ifdef INET6 +loopend: +#endif + if (m != m_old) { + switch (iface->info.ifinfo_dlt) { + case DLT_EN10MB: /* Ethernet */ + { + struct ether_header *eh; + + eh = mtod(m, struct ether_header *); + switch (ntohs(eh->ether_type)) { + case ETHERTYPE_IP: + ip = (struct ip *)(eh + 1); + break; + case ETHERTYPE_IPV6: + ip6 = (struct ip6_hdr *)(eh + 1); + break; + case ETHERTYPE_VLAN: + { + struct ether_vlan_header *evh; + + evh = mtod(m, struct ether_vlan_header *); + if (ntohs(evh->evl_proto) == ETHERTYPE_IP) { + ip = (struct ip *)(evh + 1); + break; + } else if (ntohs(evh->evl_proto) == ETHERTYPE_IPV6) { +#ifdef INET6 + ip6 = (struct ip6_hdr *)(evh + 1); + break; +#endif + } + } + default: + panic("ng_netflow entered deadcode"); + } + break; + } + case DLT_RAW: /* IP packets */ + ip = mtod(m, struct ip *); +#ifdef INET6 + if (ip->ip_v == 6) { + /* IPv6 packet */ + ip = NULL; + ip6 = mtod(m, struct ip6_hdr *); + } +#endif break; - } default: panic("ng_netflow entered deadcode"); } - break; - } - case DLT_RAW: - ip = mtod(m, struct ip *); - break; - default: - panic("ng_netflow entered deadcode"); } + upper_ptr = (caddr_t)(mtod(m, caddr_t) + off); #undef M_CHECK @@ -670,7 +980,7 @@ } else src_if_index = iface->info.ifinfo_index; - error = ng_netflow_flow_add(priv, ip, src_if_index); + error = ng_netflow_flow_add(priv, (ip != NULL) ? (caddr_t)ip : (caddr_t)ip6, upper_ptr, upper_proto, is_frag, src_if_index); bypass: if (out != NULL) { diff -urN sys/netgraph/_netflow.orig/ng_netflow.h sys/netgraph/netflow/ng_netflow.h --- sys/netgraph/_netflow.orig/ng_netflow.h 2009-09-01 02:37:44.000000000 +0400 +++ sys/netgraph/netflow/ng_netflow.h 2009-09-06 16:36:17.000000000 +0400 @@ -51,6 +51,9 @@ NGM_NETFLOW_SETIFINDEX = 5, /* set interface index */ NGM_NETFLOW_SETTIMEOUTS = 6, /* set active/inactive flow timeouts */ NGM_NETFLOW_SETCONFIG = 7, /* set flow generation options */ + NGM_NETFLOW_SETVERSION = 8, /* set flow export version */ + NGM_NETFLOW_SETTEMPLATEPERIODIC = 9, /* set v9 flow template periodic */ + NGM_NETFLOW_SETMTU = 10, /* set outgoing interface MTU */ }; /* This structure is returned by the NGM_NETFLOW_INFO message */ @@ -105,10 +108,34 @@ u_int32_t conf; /* new config */ }; +/* This structure is passed to NGM_NETFLOW_SETVERSION */ +struct ng_netflow_setversion { + u_int8_t version; /* netflow version */ +}; + +/* This structure is passed to NGM_NETFLOW_SETTEMPLATEPERIODIC */ +struct ng_netflow_settemplateperiodic { + u_int16_t time; /* max time between announce */ + u_int16_t packets; /* max packets between announce */ +}; + +/* This structure is passed to NGM_NETFLOW_SETMTU */ +struct ng_netflow_setmtu { + u_int16_t mtu; /* MTU for packet */ +}; + /* This is unique data, which identifies flow */ struct flow_rec { - struct in_addr r_src; - struct in_addr r_dst; + uint16_t flow_type; /* IPv4 L4/L3 Ipv6 L4/L3 flow, see NETFLOW_V9_FLOW* */ + uint16_t ether_proto; /* unused */ + union { + struct in_addr r_src; + struct in6_addr r_src6; + } src; + union { + struct in_addr r_dst; + struct in6_addr r_dst6; + } dst; union { struct { uint16_t s_port; /* source TCP/UDP port */ @@ -137,7 +164,10 @@ /* A flow entry which accumulates statistics */ struct flow_entry_data { struct flow_rec r; - struct in_addr next_hop; + union { + struct in_addr next_hop; + struct in6_addr next_hop6; + } n; uint16_t fle_o_ifx; /* output interface index */ #define fle_i_ifx r.misc.i.i_ifx uint8_t dst_mask; /* destination route mask bits */ @@ -146,6 +176,7 @@ u_long bytes; long first; /* uptime on first packet */ long last; /* uptime on last packet */ + uint16_t proto; /* IP/IPv6 */ u_char tcp_flags; /* cumulative OR */ }; @@ -227,6 +258,26 @@ { NULL } \ } +/* Parse the setversion structure */ +#define NG_NETFLOW_SETVERSION_TYPE { \ + { "version", &ng_parse_uint8_type }, \ + { NULL } \ +} + +/* Parse the settemplateperiodic structure */ +#define NG_NETFLOW_SETTEMPLATEPERIODIC_TYPE { \ + { "time", &ng_parse_uint16_type }, \ + { "packets", &ng_parse_uint16_type }, \ + { NULL } \ +} + +/* Parse the setmtu structure */ +#define NG_NETFLOW_SETMTU_TYPE { \ + { "mtu", &ng_parse_uint16_type }, \ + { NULL } \ +} + + /* Private hook data */ struct ng_netflow_iface { hook_p hook; /* NULL when disconnected */ @@ -270,6 +321,20 @@ item_p export_item; struct mtx export_mtx; uint32_t flow_seq; /* current flow sequence */ + /* + * RFC 3954 clause 7.3 + * "Both options MUST be configurable by the user on the Exporter." + */ + uint16_t templ_time; /* time between sending templates */ + uint16_t templ_packets; /* packets between sending templates */ + uint32_t templ_last_ts; /* unixtime of last template announce */ + uint32_t templ_last_pkt; /* packets count on last template announce */ + uint32_t sent_packets; /* packets sent by exporeter; can be reached another way ? */ + u_char version; /* Netflow export version */ + u_char flowsets_count; /* current flowsets used */ + u_char flowset_records[NETFLOW_V9_MAX_FLOWSETS - 1]; /* Count of records in each flowset */ + uint16_t mtu; /* export interface MTU */ + struct netflow_v9_flowset_header *v9_flowsets[NETFLOW_V9_MAX_FLOWSETS - 1]; /* Pointers to pre-compiled flowsets */ struct ng_netflow_iface ifaces[NG_NETFLOW_MAXIFACES]; }; @@ -286,14 +351,15 @@ #define MTAG_NETFLOW 1221656444 #define MTAG_NETFLOW_CALLED 0 +#define MTAG_NETFLOW_V9 1 /* Prototypes for netflow.c */ int ng_netflow_cache_init(priv_p); void ng_netflow_cache_flush(priv_p); void ng_netflow_copyinfo(priv_p, struct ng_netflow_info *); timeout_t ng_netflow_expire; -int ng_netflow_flow_add(priv_p, struct ip *, unsigned int src_if_index); +int ng_netflow_flow_add(priv_p, caddr_t ip_ptr, caddr_t upper_ptr, uint8_t upper_proto, uint8_t is_frag, unsigned int src_if_index); int ng_netflow_flow_show(priv_p, uint32_t last, struct ng_mesg *); - +void ng_netflow_switch_version(priv_p priv, int ver, int boot); #endif /* _KERNEL */ #endif /* _NG_NETFLOW_H_ */ diff -urN sys/modules/netgraph/netflow/Makefile.orig sys/modules/netgraph/netflow/Makefile --- sys/modules/netgraph/netflow/Makefile.orig 2009-09-06 16:31:18.000000000 +0400 +++ sys/modules/netgraph/netflow/Makefile 2009-09-06 16:33:32.000000000 +0400 @@ -3,9 +3,19 @@ # Author: Gleb Smirnoff # +.include + .PATH: ${.CURDIR}/../../../netgraph/netflow KMOD= ng_netflow -SRCS= ng_netflow.c netflow.c +SRCS= ng_netflow.c netflow.c opt_inet6.h + +.if !defined(KERNBUILDDIR) + +.if ${MK_INET6_SUPPORT} != "no" +opt_inet6.h: + echo "#define INET6 1" > ${.TARGET} +.endif +.endif .include --------------010607050501030003050405 Content-Type: text/plain; name="netflow_v9_20090906_72.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netflow_v9_20090906_72.diff" diff -urN sys/netgraph/netflow/netflow.c.orig sys/netgraph/netflow/netflow.c --- sys/netgraph/netflow/netflow.c.orig 2009-01-09 23:55:26.000000000 +0300 +++ sys/netgraph/netflow/netflow.c 2009-09-06 18:51:53.000000000 +0400 @@ -30,6 +30,8 @@ static const char rcs_id[] = "@(#) $FreeBSD: src/sys/netgraph/netflow/netflow.c,v 1.25.2.3 2009/01/09 20:55:26 mav Exp $"; +#include "opt_inet6.h" + #include #include #include @@ -37,14 +39,18 @@ #include #include #include +#include #include +#include #include #include +#include #include #include #include +#include #include #include @@ -94,12 +100,99 @@ ((t) << 6) + /* 64 */ \ ((t) << 5) + /* 32 */ \ ((t) << 3)) /* 8 */ +/* + * Defines for different neflow version dispatchers + * + */ +static int export_add(item_p, struct flow_entry *); +static int export_add_v9(item_p, struct flow_entry *); +static int export_send(priv_p, item_p, int flags); +static int export_send_v9(priv_p, item_p, int flags); + +typedef int (*record_add_ptr)(item_p, struct flow_entry *); +typedef int (*record_send_ptr)(priv_p, item_p, int); +struct _netflow_dispatchers { + record_add_ptr record_add; + record_send_ptr record_send; +}; + +static struct _netflow_dispatchers netflow_dispatcher[] = +{ + { NULL, NULL }, + { NULL, NULL }, + { NULL, NULL }, + { NULL, NULL }, + { NULL, NULL }, + { export_add, export_send }, /* Version 5 */ + { NULL, NULL }, + { NULL, NULL }, + { NULL, NULL }, + { export_add_v9, export_send_v9 }, /* Version 9 */ + { NULL, NULL } +}; + +record_add_ptr record_add = NULL; +record_send_ptr record_send = NULL; MALLOC_DECLARE(M_NETFLOW_HASH); MALLOC_DEFINE(M_NETFLOW_HASH, "netflow_hash", "NetFlow hash"); -static int export_add(item_p, struct flow_entry *); -static int export_send(priv_p, item_p, int flags); + +static struct netflow_v9_template _netflow_v9_record_ipv4_tcp[] = +{ + { NETFLOW_V9_FIELD_IPV4_SRC_ADDR, 4}, + { NETFLOW_V9_FIELD_IPV4_DST_ADDR, 4}, + { NETFLOW_V9_FIELD_IPV4_NEXT_HOP, 4}, + { NETFLOW_V9_FIELD_INPUT_SNMP, 2}, + { NETFLOW_V9_FIELD_OUTPUT_SNMP, 2}, + { NETFLOW_V9_FIELD_IN_PKTS, sizeof(cntr)}, + { NETFLOW_V9_FIELD_IN_BYTES, sizeof(cntr)}, + { NETFLOW_V9_FIELD_OUT_PKTS, sizeof(cntr)}, + { NETFLOW_V9_FIELD_OUT_BYTES, sizeof(cntr)}, + { NETFLOW_V9_FIELD_FIRST_SWITCHED, 4}, + { NETFLOW_V9_FIELD_LAST_SWITCHED, 4}, + { NETFLOW_V9_FIELD_L4_SRC_PORT, 2}, + { NETFLOW_V9_FIELD_L4_DST_PORT, 2}, + { NETFLOW_V9_FIELD_TCP_FLAGS, 1}, + { NETFLOW_V9_FIELD_PROTOCOL, 1}, + { NETFLOW_V9_FIELD_TOS, 1}, + { NETFLOW_V9_FIELD_SRC_AS, 4}, + { NETFLOW_V9_FIELD_DST_AS, 4}, + { NETFLOW_V9_FIELD_SRC_MASK, 1}, + { NETFLOW_V9_FIELD_DST_MASK, 1}, + {0, 0} +}; + +static struct netflow_v9_template _netflow_v9_record_ipv6_tcp[] = +{ + { NETFLOW_V9_FIELD_IPV6_SRC_ADDR, 16}, + { NETFLOW_V9_FIELD_IPV6_DST_ADDR, 16}, + { NETFLOW_V9_FIELD_IPV6_NEXT_HOP, 16}, + { NETFLOW_V9_FIELD_INPUT_SNMP, 2}, + { NETFLOW_V9_FIELD_OUTPUT_SNMP, 2}, + { NETFLOW_V9_FIELD_IN_PKTS, sizeof(cntr)}, + { NETFLOW_V9_FIELD_IN_BYTES, sizeof(cntr)}, + { NETFLOW_V9_FIELD_OUT_PKTS, sizeof(cntr)}, + { NETFLOW_V9_FIELD_OUT_BYTES, sizeof(cntr)}, + { NETFLOW_V9_FIELD_FIRST_SWITCHED, 4}, + { NETFLOW_V9_FIELD_LAST_SWITCHED, 4}, + { NETFLOW_V9_FIELD_L4_SRC_PORT, 2}, + { NETFLOW_V9_FIELD_L4_DST_PORT, 2}, + { NETFLOW_V9_FIELD_TCP_FLAGS, 1}, + { NETFLOW_V9_FIELD_PROTOCOL, 1}, + { NETFLOW_V9_FIELD_TOS, 1}, + { NETFLOW_V9_FIELD_SRC_AS, 4}, + { NETFLOW_V9_FIELD_DST_AS, 4}, + { NETFLOW_V9_FIELD_SRC_MASK, 1}, + { NETFLOW_V9_FIELD_DST_MASK, 1}, + {0, 0} +}; + + +static int generate_v9_templates(priv_p priv); + +MALLOC_DECLARE(M_NETFLOW_GENERAL); +MALLOC_DEFINE(M_NETFLOW_GENERAL, "netflog_general", "plog, templates data"); /* Generate hash for a given flow record. */ static __inline uint32_t @@ -108,10 +201,24 @@ switch (r->r_ip_p) { case IPPROTO_TCP: case IPPROTO_UDP: - return FULL_HASH(r->r_src.s_addr, r->r_dst.s_addr, + return FULL_HASH(r->src.r_src.s_addr, r->dst.r_dst.s_addr, + r->r_sport, r->r_dport); + default: + return ADDR_HASH(r->src.r_src.s_addr, r->dst.r_dst.s_addr); + } +} + +/* Generate hash for a given flow record. Use lower 4 octets from v6 addresses */ +static __inline uint32_t +ip6_hash(struct flow_rec *r) +{ + switch (r->r_ip_p) { + case IPPROTO_TCP: + case IPPROTO_UDP: + return FULL_HASH(r->src.r_src6.__u6_addr.__u6_addr32[3], r->dst.r_dst6.__u6_addr.__u6_addr32[3], r->r_sport, r->r_dport); default: - return ADDR_HASH(r->r_src.s_addr, r->r_dst.s_addr); + return ADDR_HASH(r->src.r_src6.__u6_addr.__u6_addr32[3], r->dst.r_dst6.__u6_addr.__u6_addr32[3]); } } @@ -126,6 +233,7 @@ atomic_add_32(&priv->info.nfinfo_used, 1); + return (0); } @@ -141,6 +249,7 @@ /* * Detach export datagram from priv, if there is any. * If there is no, allocate a new one. + * -- V9/IPv6 ready */ static item_p get_export_dgram(priv_p priv) @@ -166,14 +275,163 @@ return (NULL); dgram = mtod(m, struct netflow_v5_export_dgram *); dgram->header.count = 0; - dgram->header.version = htons(NETFLOW_V5); + dgram->header.version = htons(priv->version); + + if (priv->version == NETFLOW_V9) { + atomic_fetchadd_32(&priv->sent_packets, 1); + + /* + * Let's insert mbuf tag to store some info + */ + struct netflow_v9_mbuf_tag *t; + struct m_tag *mt = m_tag_alloc(MTAG_NETFLOW, MTAG_NETFLOW_V9, sizeof(struct netflow_v9_mbuf_tag), M_NOWAIT); + if (mt == NULL) { + m_freem(m); + return (NULL); + } + + m_tag_init(m); + m_tag_prepend(m, mt); + t = (struct netflow_v9_mbuf_tag *)(mt + 1); + t->length = sizeof(struct netflow_v9_header); + t->count = 0; + t->mtu = priv->mtu; + t->flow_header = t->length; + + /* + * Check if we need to insert templates into packet + */ + + struct timespec ts; + struct netflow_v9_flowset_header *fl; + + getnanotime(&ts); + if ((ts.tv_sec >= priv->templ_time + priv->templ_last_ts) || (priv->sent_packets >= priv->templ_packets + priv->templ_last_pkt)) { + //vlog("INSERTING TEMPLATE: ts: %lu last: %u packets: %u last: %u delay: %u", ts.tv_sec, priv->templ_last_ts, priv->sent_packets, priv->templ_last_pkt, priv->templ_time); + atomic_store_rel_32(&priv->templ_last_ts, ts.tv_sec); + atomic_store_rel_32(&priv->templ_last_pkt, priv->sent_packets); + //vlog("ts: %lu last_t: %u last_p: %u delay: %u", ts.tv_sec, priv->templ_last_ts, priv->templ_last_pkt, priv->templ_time); + + fl = priv->v9_flowsets[0]; + bcopy(fl, (char *)dgram + t->length, ntohs(fl->length)); + + t->length += ntohs(fl->length); + t->flow_header = t->length; + t->count += priv->flowset_records[0]; + } + + } } return (item); } /* + * Pre-compiles flow exporter for all possible FlowSets + * so we can add flowset to packet via simple memcpy() + */ +#define __push(x) *p++ = htons((x)) +static int +generate_v9_templates(priv_p priv) +{ + uint16_t *p, *template_fields_cnt; + int cnt; + + int flowset_size = sizeof(struct netflow_v9_flowset_header) + + _NETFLOW_V9_TEMPLATE_SIZE(_netflow_v9_record_ipv4_tcp) + /* netflow_v9_record_ipv4_tcp */ + _NETFLOW_V9_TEMPLATE_SIZE(_netflow_v9_record_ipv6_tcp); /* netflow_v9_record_ipv6_tcp */ + + priv->v9_flowsets[0] = malloc(flowset_size, M_NETFLOW_GENERAL, M_WAITOK | M_ZERO); + if (priv->v9_flowsets[0] == NULL) + return (ENOMEM); + + + if (flowset_size % 4) + flowset_size += 4 - (flowset_size % 4); /* Padding to 4-byte boundary */ + + priv->flowsets_count = 1; + p = (uint16_t *)priv->v9_flowsets[0]; + *p++ = 0; /* Flowset ID, 0 is reserved for Template FlowSets */ + *p++ = htons(flowset_size); /* Total FlowSet length */ + + /* + * Most common TCP/UDP IPv4 template, ID = 256 + */ + *p++ = htons(0x100 + NETFLOW_V9_FLOW_V4_L4); + template_fields_cnt = p++; + for (cnt = 0; _netflow_v9_record_ipv4_tcp[cnt].field_id != 0; cnt++) { + *p++ = htons(_netflow_v9_record_ipv4_tcp[cnt].field_id); + *p++ = htons(_netflow_v9_record_ipv4_tcp[cnt].field_length); + } + *template_fields_cnt = htons(cnt); + + /* + * TCP/UDP IPv6 template, ID = 257 + */ + *p++ = htons(0x100 + NETFLOW_V9_FLOW_V6_L4); + template_fields_cnt = p++; + for (cnt = 0; _netflow_v9_record_ipv6_tcp[cnt].field_id != 0; cnt++) { + *p++ = htons(_netflow_v9_record_ipv6_tcp[cnt].field_id); + *p++ = htons(_netflow_v9_record_ipv6_tcp[cnt].field_length); + } + *template_fields_cnt = htons(cnt); + + + priv->flowset_records[0] = 2; + return (0); +} + +/* + * Switches version used for netflow export + * + */ +void +ng_netflow_switch_version(priv_p priv, int ver, int boot) +{ + item_p item = NULL; + + if ((ver != NETFLOW_V9) && (ver != NETFLOW_V5)) + return; + + if ((ver == priv->version) && (boot == 0)) + return; + + /* + * All new threads acquiring export datagram will wait for lock + * so we can change pointers. + * Existing threads with export datagram already held will call + * wrong export function which will do version check at the beginning + */ + + mtx_lock(&priv->export_mtx); + /* XXX: Need to be machine-independent here */ + record_add = netflow_dispatcher[ver].record_add; + record_send = netflow_dispatcher[ver].record_send; + //atomic_store_rel_ptr((unsigned long *)record_add, (unsigned long)netflow_dispatcher[ver].record_add); + //atomic_store_rel_ptr((unsigned long *)record_send, (unsigned long)netflow_dispatcher[ver].record_send); + item = priv->export_item; + priv->export_item = NULL; + mtx_unlock(&priv->export_mtx); + + if (ver == NETFLOW_V9) { + priv->templ_last_pkt = 0; + priv->templ_last_ts = 0; + } + + //vlog("NEW: add=%p send=%p", record_add, record_send); + + if (item != NULL) + (*netflow_dispatcher[priv->version].record_send)(priv, item, NG_NOFLAGS); + + if (boot) + log(LOG_DEBUG, "ng_netflow: v%d export started\n", ver); + else + log(LOG_DEBUG, "ng_netflow: export switched: v%d -> v%d\n", priv->version, ver); + priv->version = ver; +} + +/* * Re-attach incomplete datagram back to priv. * If there is already another one, then send incomplete. */ static void @@ -190,13 +448,14 @@ mtx_unlock(&priv->export_mtx); } else { mtx_unlock(&priv->export_mtx); - export_send(priv, item, flags); + (*record_send)(priv, item, flags); } } /* * The flow is over. Call export_add() and free it. If datagram is * full, then call export_send(). + * -- v9/IPv6 nearly ready */ static __inline void expire_flow(priv_p priv, item_p *item, struct flow_entry *fle, int flags) @@ -208,8 +467,8 @@ uma_zfree_arg(priv->zone, fle, priv); return; } - if (export_add(*item, fle) > 0) { - export_send(priv, *item, flags); + if ((*record_add)(*item, fle) > 0) { + (*record_send)(priv, *item, flags); *item = NULL; } uma_zfree_arg(priv->zone, fle, priv); @@ -234,12 +493,15 @@ * to be sure. */ static __inline int -hash_insert(priv_p priv, struct flow_hash_entry *hsh, struct flow_rec *r, +hash_insert(priv_p priv, struct flow_hash_entry *hsh, struct flow_rec *r, uint16_t eproto, int plen, uint8_t tcp_flags) { struct flow_entry *fle; - struct route ro; - struct sockaddr_in *sin; + struct sockaddr_in sin; +#ifdef INET6 + struct sockaddr_in6 sin6; +#endif + struct rtentry *rt; mtx_assert(&hsh->mtx, MA_OWNED); @@ -257,6 +519,7 @@ bcopy(r, &fle->f.r, sizeof(struct flow_rec)); fle->f.bytes = plen; fle->f.packets = 1; + fle->f.proto = eproto; fle->f.tcp_flags = tcp_flags; fle->f.first = fle->f.last = time_uptime; @@ -265,52 +528,93 @@ * First we do route table lookup on destination address. So we can * fill in out_ifx, dst_mask, nexthop, and dst_as in future releases. */ - bzero((caddr_t)&ro, sizeof(ro)); - sin = (struct sockaddr_in *)&ro.ro_dst; - sin->sin_len = sizeof(*sin); - sin->sin_family = AF_INET; - sin->sin_addr = fle->f.r.r_dst; - /* XXX MRT 0 as a default.. need the m here to get fib */ - rtalloc_ign_fib(&ro, RTF_CLONING, 0); - if (ro.ro_rt != NULL) { - struct rtentry *rt = ro.ro_rt; - - fle->f.fle_o_ifx = rt->rt_ifp->if_index; - - if (rt->rt_flags & RTF_GATEWAY && - rt->rt_gateway->sa_family == AF_INET) - fle->f.next_hop = - ((struct sockaddr_in *)(rt->rt_gateway))->sin_addr; - - if (rt_mask(rt)) - fle->f.dst_mask = bitcount32(((struct sockaddr_in *) - rt_mask(rt))->sin_addr.s_addr); - else if (rt->rt_flags & RTF_HOST) - /* Give up. We can't determine mask :( */ - fle->f.dst_mask = 32; - - RTFREE(ro.ro_rt); - } - - /* Do route lookup on source address, to fill in src_mask. */ - - bzero((caddr_t)&ro, sizeof(ro)); - sin = (struct sockaddr_in *)&ro.ro_dst; - sin->sin_len = sizeof(*sin); - sin->sin_family = AF_INET; - sin->sin_addr = fle->f.r.r_src; - rtalloc_ign_fib(&ro, RTF_CLONING, 0); /* XXX MRT */ - if (ro.ro_rt != NULL) { - struct rtentry *rt = ro.ro_rt; - - if (rt_mask(rt)) - fle->f.src_mask = bitcount32(((struct sockaddr_in *) - rt_mask(rt))->sin_addr.s_addr); - else if (rt->rt_flags & RTF_HOST) - /* Give up. We can't determine mask :( */ - fle->f.src_mask = 32; - - RTFREE(ro.ro_rt); + if (eproto == ETHERTYPE_IP) { + bzero(&sin, sizeof(sin)); + sin.sin_len = sizeof(struct sockaddr_in); + sin.sin_family = AF_INET; + sin.sin_addr = fle->f.r.dst.r_dst; + /* XXX MRT 0 as a default.. need the m here to get fib */ + rt = rtalloc1_fib((struct sockaddr *)&sin, 0, 0, 0); + if (rt != NULL) { + fle->f.fle_o_ifx = rt->rt_ifp->if_index; + + if (rt->rt_flags & RTF_GATEWAY && + rt->rt_gateway->sa_family == AF_INET) + fle->f.n.next_hop = + ((struct sockaddr_in *)(rt->rt_gateway))->sin_addr; + + if (rt_mask(rt)) + fle->f.dst_mask = bitcount32(((struct sockaddr_in *) + rt_mask(rt))->sin_addr.s_addr); + else if (rt->rt_flags & RTF_HOST) + /* Give up. We can't determine mask :( */ + fle->f.dst_mask = 32; + + RTFREE_LOCKED(rt); + } + + /* Do route lookup on source address, to fill in src_mask. */ + bzero(&sin, sizeof(sin)); + sin.sin_len = sizeof(struct sockaddr_in); + sin.sin_family = AF_INET; + sin.sin_addr = fle->f.r.src.r_src; + /* XXX MRT 0 as a default revisit. need the mbuf for fib*/ + rt = rtalloc1_fib((struct sockaddr *)&sin, 0, 0, 0); + if (rt != NULL) { + if (rt_mask(rt)) + fle->f.src_mask = bitcount32(((struct sockaddr_in *) + rt_mask(rt))->sin_addr.s_addr); + else if (rt->rt_flags & RTF_HOST) + /* Give up. We can't determine mask :( */ + fle->f.src_mask = 32; + + RTFREE_LOCKED(rt); + } + } else { +#ifdef INET6 + bzero(&sin6, sizeof(sin6)); + sin6.sin6_len = sizeof(struct sockaddr_in6); + sin6.sin6_family = AF_INET6; + sin6.sin6_addr = fle->f.r.dst.r_dst6; + /* XXX fib works for AF_INET only */ + rt = rtalloc1_fib((struct sockaddr *)&sin6, 0, 0, 0); + if (rt != NULL) { + fle->f.fle_o_ifx = rt->rt_ifp->if_index; + + if (rt->rt_flags & RTF_GATEWAY && + rt->rt_gateway->sa_family == AF_INET6) + fle->f.n.next_hop6 = + ((struct sockaddr_in6 *)(rt->rt_gateway))->sin6_addr; + if (rt_mask(rt)) +/* + fle->f.dst_mask = bitcount32(((struct sockaddr_in6 *) + rt_mask(rt))->sin_addr.s_addr); + else if (rt->rt_flags & RTF_HOST) */ + /* Give up. We can't determine mask :( */ + fle->f.dst_mask = 128; + + RTFREE_LOCKED(rt); + } + + /* Do route lookup on source address, to fill in src_mask. */ + bzero(&sin6, sizeof(sin6)); + sin6.sin6_len = sizeof(struct sockaddr_in6); + sin6.sin6_family = AF_INET6; + sin6.sin6_addr = fle->f.r.src.r_src6; + /* XXX MRT 0 as a default revisit. need the mbuf for fib*/ + rt = rtalloc1_fib((struct sockaddr *)&sin6, 0, 0, 0); + if (rt != NULL) { +/* + if (rt_mask(rt)) + fle->f.src_mask = bitcount32(((struct sockaddr_in6 *) + rt_mask(rt))->sin_addr.s_addr); + else if (rt->rt_flags & RTF_HOST) */ + /* Give up. We can't determine mask :( */ + fle->f.src_mask = 128; + + RTFREE_LOCKED(rt); + } +#endif } /* Push new flow at the and of hash. */ @@ -354,6 +658,10 @@ mtx_init(&priv->export_mtx, "export dgram lock", NULL, MTX_DEF); + generate_v9_templates(priv); + + ng_netflow_switch_version(priv, priv->version, 1); + return (0); } @@ -366,6 +674,7 @@ item_p item = NULL; int i; + /* * We are going to free probably billable data. * Expire everything before freeing it. @@ -378,7 +687,7 @@ } if (item != NULL) - export_send(priv, item, NG_QUEUE); + (*record_send)(priv, item, NG_QUEUE); uma_zdestroy(priv->zone); @@ -390,46 +699,34 @@ if (priv->hash) FREE(priv->hash, M_NETFLOW_HASH); + /* FreeFlow Tables */ + for (i = 0; i < priv->flowsets_count; i++) + free(priv->v9_flowsets[i], M_NETFLOW_GENERAL); + mtx_destroy(&priv->export_mtx); } -/* Insert packet from into flow cache. */ +/* + * Insert packet from into flow cache. Assume size/version check passed + */ int -ng_netflow_flow_add(priv_p priv, struct ip *ip, unsigned int src_if_index) +ng_netflow_flow_add(priv_p priv, caddr_t ip_ptr, caddr_t upper_ptr, uint8_t upper_proto, uint8_t is_frag, unsigned int src_if_index) { register struct flow_entry *fle, *fle1; struct flow_hash_entry *hsh; struct flow_rec r; + struct ip *ip = NULL; +#ifdef INET6 + struct ip6_hdr *ip6 = NULL; +#endif item_p item = NULL; - int hlen, plen; + int plen; int error = 0; uint8_t tcp_flags = 0; - - /* Try to fill flow_rec r */ - bzero(&r, sizeof(r)); - /* check version */ - if (ip->ip_v != IPVERSION) - return (EINVAL); - - /* verify min header length */ - hlen = ip->ip_hl << 2; - - if (hlen < sizeof(struct ip)) - return (EINVAL); - - r.r_src = ip->ip_src; - r.r_dst = ip->ip_dst; - - /* save packet length */ - plen = ntohs(ip->ip_len); - - r.r_ip_p = ip->ip_p; - r.r_tos = ip->ip_tos; - - r.r_i_ifx = src_if_index; + uint16_t eproto; /* - * XXX NOTE: only first fragment of fragmented TCP, UDP and + * XXX Fragmentation NOTE: only first fragment of fragmented TCP, UDP and * ICMP packet will be recorded with proper s_port and d_port. * Following fragments will be recorded simply as IP packet with * ip_proto = ip->ip_p and s_port, d_port set to zero. @@ -437,22 +734,91 @@ * ip packet assebmling here. Anyway, (in)famous trafd works this way - * and nobody complains yet :) */ - if ((ip->ip_off & htons(IP_OFFMASK)) == 0) - switch(r.r_ip_p) { - case IPPROTO_TCP: - { - register struct tcphdr *tcp; - - tcp = (struct tcphdr *)((caddr_t )ip + hlen); - r.r_sport = tcp->th_sport; - r.r_dport = tcp->th_dport; - tcp_flags = tcp->th_flags; - break; + + /* Try to fill flow_rec r */ + bzero(&r, sizeof(r)); + ip = (struct ip *)ip_ptr; + if (ip->ip_v == IPVERSION) { + eproto = ETHERTYPE_IP; + r.src.r_src = ip->ip_src; + r.dst.r_dst = ip->ip_dst; + + /* Assume L$ template by default */ + r.flow_type = NETFLOW_V9_FLOW_V4_L4; + + /* save packet length */ + plen = ntohs(ip->ip_len); + + r.r_tos = ip->ip_tos; + + if (is_frag == 0) { + switch(upper_proto) { + case IPPROTO_TCP: + { + register struct tcphdr *tcp; + + tcp = (struct tcphdr *)upper_ptr; + r.r_ports = *(uint32_t *)upper_ptr; + tcp_flags = tcp->th_flags; + /* r.flow_type = NETFLOW_V9_FLOW_V4_L4; */ + break; + } + case IPPROTO_UDP: + case IPPROTO_SCTP: + { + r.r_ports = *(uint32_t *)upper_ptr; + /* r.flow_type = NETFLOW_V9_FLOW_V4_L4; */ + break; + } + + } } + + } else { +#ifdef INET6 + /* IPv6 traffic */ + ip = NULL; + ip6 = (struct ip6_hdr *)ip_ptr; + eproto = ETHERTYPE_IPV6; + + r.src.r_src6 = ip6->ip6_src; + r.dst.r_dst6 = ip6->ip6_dst; + + /* Assume L4 template by default */ + r.flow_type = NETFLOW_V9_FLOW_V6_L4; + + /* save packet length */ + plen = ntohs(ip6->ip6_plen) + sizeof(struct ip6_hdr); + + //r.r_tos = ip->ip_tos; + + if (is_frag == 0) { + switch(upper_proto) { + case IPPROTO_TCP: + { + register struct tcphdr *tcp; + + tcp = (struct tcphdr *)upper_ptr; + r.r_ports = *(uint32_t *)upper_ptr; + tcp_flags = tcp->th_flags; + /* r.flow_type = NETFLOW_V9_FLOW_V6_L4; */ + break; + } case IPPROTO_UDP: - r.r_ports = *(uint32_t *)((caddr_t )ip + hlen); - break; + case IPPROTO_SCTP: + { + r.r_ports = *(uint32_t *)upper_ptr; + /* r.flow_type = NETFLOW_V9_FLOW_V6_L4; */ + break; + } + + } } +#endif + } + + r.r_ip_p = upper_proto; + r.r_i_ifx = src_if_index; /* Update node statistics. XXX: race... */ priv->info.nfinfo_packets ++; @@ -493,7 +859,7 @@ * - it is going to overflow counter */ if (tcp_flags & TH_FIN || tcp_flags & TH_RST || AGED(fle) || - (fle->f.bytes >= (UINT_MAX - IF_MAXMTU)) ) { + (fle->f.bytes >= (cntr_max - IF_MAXMTU)) ) { TAILQ_REMOVE(&hsh->head, fle, fle_hash); expire_flow(priv, &item, fle, NG_QUEUE); atomic_add_32(&priv->info.nfinfo_act_exp, 1); @@ -509,7 +875,7 @@ } } } else /* A new flow entry. */ - error = hash_insert(priv, hsh, &r, plen, tcp_flags); + error = hash_insert(priv, hsh, &r, eproto, plen, tcp_flags); mtx_unlock(&hsh->mtx); @@ -618,6 +984,65 @@ return (error); } +/* We have full datagram in privdata. Send it to export hook. */ +static int +export_send_v9(priv_p priv, item_p item, int flags) +{ + struct mbuf *m = NGI_M(item); + struct netflow_v9_export_dgram *dgram = mtod(m, + struct netflow_v9_export_dgram *); + struct netflow_v9_header *header = &dgram->header; + struct timespec ts; + int error = 0; + uint16_t len = 0; + + struct netflow_v9_mbuf_tag *t; + struct netflow_v9_flowset_header *fs = NULL; + struct m_tag *mt = m_tag_locate(m, MTAG_NETFLOW, MTAG_NETFLOW_V9, NULL); + + if (mt == NULL) { + /* */ + log(LOG_DEBUG, "ng_netflow: V9 export packet without tag!\n"); + return (0); + } + + t = (struct netflow_v9_mbuf_tag *)(mt + 1); + + /* Close FlowSet if not closed */ + if (t->length != t->flow_header) { + fs = (struct netflow_v9_flowset_header *)(mtod(m, char *) + t->flow_header); + len = (uint16_t)(t->length - t->flow_header); + if (len % 4) { + t->length += 4 - (len % 4); + len += 4 - (len % 4); + } + fs->length = htons(len); + } + + + + /* Fill mbuf header. */ + m->m_len = m->m_pkthdr.len = t->length; + + /* Fill export header. */ + header->count = t->count; + header->sys_uptime = htonl(MILLIUPTIME(time_uptime)); + getnanotime(&ts); + header->unix_secs = htonl(ts.tv_sec); + header->seq_num = htonl(atomic_fetchadd_32(&priv->flow_seq, 1)); + header->count = htons(t->count); + header->source_id = htonl(NG_NODE_ID(priv->node)); + + /* remove tag */ + m_tag_delete_chain(m, NULL); + + if (priv->export != NULL) + NG_FWD_ITEM_HOOK_FLAGS(error, item, priv->export, flags); + else + NG_FREE_ITEM(item); + + return (error); +} /* Add export record to dgram. */ static int @@ -635,9 +1060,9 @@ ("ng_netflow: export too big")); /* Fill in export record. */ - rec->src_addr = fle->f.r.r_src.s_addr; - rec->dst_addr = fle->f.r.r_dst.s_addr; - rec->next_hop = fle->f.next_hop.s_addr; + rec->src_addr = fle->f.r.src.r_src.s_addr; + rec->dst_addr = fle->f.r.dst.r_dst.s_addr; + rec->next_hop = fle->f.n.next_hop.s_addr; rec->i_ifx = htons(fle->f.fle_i_ifx); rec->o_ifx = htons(fle->f.fle_o_ifx); rec->packets = htonl(fle->f.packets); @@ -661,6 +1086,135 @@ return (0); } +/* Add V9 record to dgram. */ +static int +export_add_v9(item_p item, struct flow_entry *fle) +{ + size_t len = 0; + uint16_t new_flow = 0; + void *offset_ptr; + struct netflow_v9_mbuf_tag *t; + struct netflow_v9_flowset_header *fs = NULL; + struct mbuf *m = NGI_M(item); + struct m_tag *mt = m_tag_locate(m, MTAG_NETFLOW, MTAG_NETFLOW_V9, NULL); + + if (mt == NULL) { + /* */ + log(LOG_DEBUG, "ng_netflow: V9 export packet without tag!\n"); + return (0); + } + + t = (struct netflow_v9_mbuf_tag *)(mt + 1); + offset_ptr = (mtod(m, char *) + t->length); + + /* Check if new records has the same template */ + if (fle->f.r.flow_type != t->flow_type) { + new_flow = 1; + + /* 'Close' old FlowSet */ + fs = (struct netflow_v9_flowset_header *)(mtod(m, char *) + t->flow_header); + len = (uint16_t)(t->length - t->flow_header); + if (len % 4) { + t->length += 4 - (len % 4); + len += 4 - (len % 4); + } + fs->length = htons(len); + + /* Prepare 'new', but do not modify any counters here because switch can fail */ + t->flow_type = NETFLOW_V9_FLOW_FAKE; + t->flow_header = t->length; + fs = (struct netflow_v9_flowset_header *)(mtod(m, char *) + t->length); + offset_ptr = (fs + 1); + } + + + switch (fle->f.r.flow_type) { + case NETFLOW_V9_FLOW_V4_L4: + { + /* IPv4 TCP/UDP/[SCTP] */ + struct netflow_v9_record_ipv4_tcp *rec = (struct netflow_v9_record_ipv4_tcp *)offset_ptr; + + + rec->src_addr = fle->f.r.src.r_src.s_addr; + rec->dst_addr = fle->f.r.dst.r_dst.s_addr; + rec->next_hop = fle->f.n.next_hop.s_addr; + rec->i_ifx = htons(fle->f.fle_i_ifx); + rec->o_ifx = htons(fle->f.fle_o_ifx); + rec->i_packets = htonl(fle->f.packets); + rec->i_octets = htonl(fle->f.bytes); + rec->o_packets = htonl(0); + rec->o_octets = htonl(0); + rec->first = htonl(MILLIUPTIME(fle->f.first)); + rec->last = htonl(MILLIUPTIME(fle->f.last)); + rec->s_port = fle->f.r.r_sport; + rec->d_port = fle->f.r.r_dport; + rec->flags = fle->f.tcp_flags; + rec->prot = fle->f.r.r_ip_p; + rec->tos = fle->f.r.r_tos; + rec->dst_mask = fle->f.dst_mask; + rec->src_mask = fle->f.src_mask; + + /* Not supported fields. */ + rec->src_as = rec->dst_as = 0; + + len = sizeof(struct netflow_v9_record_ipv4_tcp); + break; + } +#ifdef INET6 + case NETFLOW_V9_FLOW_V6_L4: + { + /* IPv6 TCP/UDP/[SCTP] */ + struct netflow_v9_record_ipv6_tcp *rec = (struct netflow_v9_record_ipv6_tcp *)offset_ptr; + + /* ACHTUNG! unchecked code! */ + rec->src_addr = fle->f.r.src.r_src6; + rec->dst_addr = fle->f.r.dst.r_dst6; + rec->next_hop = fle->f.n.next_hop6; + rec->i_ifx = htons(fle->f.fle_i_ifx); + rec->o_ifx = htons(fle->f.fle_o_ifx); + rec->i_packets = htonl(fle->f.packets); + rec->i_octets = htonl(fle->f.bytes); + rec->first = htonl(MILLIUPTIME(fle->f.first)); + rec->last = htonl(MILLIUPTIME(fle->f.last)); + rec->s_port = fle->f.r.r_sport; + rec->d_port = fle->f.r.r_dport; + rec->flags = fle->f.tcp_flags; + rec->prot = fle->f.r.r_ip_p; + rec->tos = fle->f.r.r_tos; + rec->dst_mask = fle->f.dst_mask; + rec->src_mask = fle->f.src_mask; + + /* Not supported fields. */ + rec->src_as = rec->dst_as = 0; + + len = sizeof(struct netflow_v9_record_ipv6_tcp); + break; + } +#endif + default: + { + log(LOG_DEBUG, "ng_netflow: Don't know what to do with %d flow type!\n", fle->f.r.flow_type); + return (0); + } + } + + if (new_flow) { + /* Generate data segment ID */ + fs->id = htons(0x100 + fle->f.r.flow_type); + t->flow_type = fle->f.r.flow_type; + t->length += sizeof(struct netflow_v9_flowset_header); + } + + t->length += len; + t->count++; + + if (t->length + NETFLOW_V9_MAX_RECORD_SIZE + 4 >= _NETFLOW_V9_MAX_SIZE(t->mtu)) + return (1); /* end of datagram */ + else + return (0); +} + + /* Periodic flow expiry run. */ void ng_netflow_expire(void *arg) diff -urN sys/netgraph/netflow/ng_netflow.c.orig sys/netgraph/netflow/ng_netflow.c --- sys/netgraph/netflow/ng_netflow.c.orig 2009-01-09 23:55:26.000000000 +0300 +++ sys/netgraph/netflow/ng_netflow.c 2009-09-06 18:38:40.000000000 +0400 @@ -30,6 +30,8 @@ static const char rcs_id[] = "@(#) $FreeBSD: src/sys/netgraph/netflow/ng_netflow.c,v 1.14.2.4 2009/01/09 20:55:26 mav Exp $"; +#include "opt_inet6.h" + #include #include #include @@ -48,8 +50,11 @@ #include #include #include +#include +#include #include #include +#include #include #include @@ -114,6 +119,30 @@ &ng_netflow_setconfig_type_fields }; +/* Parse type for ng_netflow_setversion */ +static const struct ng_parse_struct_field ng_netflow_setversion_type_fields[] + = NG_NETFLOW_SETVERSION_TYPE; +static const struct ng_parse_type ng_netflow_setversion_type = { + &ng_parse_struct_type, + &ng_netflow_setversion_type_fields +}; + +/* Parse type for ng_netflow_settemplateperiodic */ +static const struct ng_parse_struct_field ng_netflow_settemplateperiodic_type_fields[] + = NG_NETFLOW_SETTEMPLATEPERIODIC_TYPE; +static const struct ng_parse_type ng_netflow_settemplateperiodic_type = { + &ng_parse_struct_type, + &ng_netflow_settemplateperiodic_type_fields +}; + +/* Parse type for ng_netflow_setmtu */ +static const struct ng_parse_struct_field ng_netflow_setmtu_type_fields[] + = NG_NETFLOW_SETMTU_TYPE; +static const struct ng_parse_type ng_netflow_setmtu_type = { + &ng_parse_struct_type, + &ng_netflow_setmtu_type_fields +}; + /* List of commands and how to convert arguments to/from ASCII */ static const struct ng_cmdlist ng_netflow_cmds[] = { { @@ -158,6 +187,27 @@ &ng_netflow_setconfig_type, NULL }, + { + NGM_NETFLOW_COOKIE, + NGM_NETFLOW_SETVERSION, + "setversion", + &ng_netflow_setversion_type, + NULL + }, + { + NGM_NETFLOW_COOKIE, + NGM_NETFLOW_SETTEMPLATEPERIODIC, + "settemplateperiodic", + &ng_netflow_settemplateperiodic_type, + NULL + }, + { + NGM_NETFLOW_COOKIE, + NGM_NETFLOW_SETMTU, + "setmtu", + &ng_netflow_setmtu_type, + NULL + }, { 0 } }; @@ -202,6 +252,13 @@ for (i = 0; i < NG_NETFLOW_MAXIFACES; i++) priv->ifaces[i].info.conf = NG_NETFLOW_CONF_INGRESS; + /* Set v9 defaults */ + priv->version = NETFLOW_V9; + priv->templ_time = NETFLOW_V9_MAX_TIME_TEMPL; + priv->templ_packets = NETFLOW_V9_MAX_PACKETS_TEMPL; + priv->mtu = BASE_MTU; + priv->flow_seq = 0; + /* Initialize callout handle */ callout_init(&priv->exp_callout, CALLOUT_MPSAFE); @@ -434,6 +491,52 @@ break; } + case NGM_NETFLOW_SETVERSION: + { + struct ng_netflow_setversion *set; + + if (msg->header.arglen != sizeof(struct ng_netflow_setversion)) + ERROUT(EINVAL); + + set = (struct ng_netflow_setversion *)msg->data; + if ((set->version != NETFLOW_V9) && (set->version != NETFLOW_V5)) + ERROUT(EINVAL); + + ng_netflow_switch_version(priv, set->version, 0); + + break; + } + case NGM_NETFLOW_SETTEMPLATEPERIODIC: + { + struct ng_netflow_settemplateperiodic *set; + + if (msg->header.arglen != sizeof(struct ng_netflow_settemplateperiodic)) + ERROUT(EINVAL); + + set = (struct ng_netflow_settemplateperiodic *)msg->data; + + /* XXX: Set atomic here */ + priv->templ_packets = set->packets; + priv->templ_time = set->time; + + break; + } + case NGM_NETFLOW_SETMTU: + { + struct ng_netflow_setmtu *set; + + if (msg->header.arglen != sizeof(struct ng_netflow_setmtu)) + ERROUT(EINVAL); + + set = (struct ng_netflow_setmtu *)msg->data; + if ((set->mtu < MIN_MTU) || (set->mtu > MAX_MTU)) + ERROUT(EINVAL); + + /* XXX: Set atomic here */ + priv->mtu = set->mtu; + + break; + } case NGM_NETFLOW_SHOW: { uint32_t *last; @@ -481,12 +584,15 @@ const priv_p priv = NG_NODE_PRIVATE(node); const iface_p iface = NG_HOOK_PRIVATE(hook); hook_p out; - struct mbuf *m = NULL; - struct ip *ip; + struct mbuf *m, *m_old = NULL; + struct ip *ip = NULL; + struct ip6_hdr *ip6 = NULL; struct m_tag *mtag; - int pullup_len = 0; + int pullup_len = 0, off = 0; + uint8_t upper_proto = 0, is_frag = 0; int error = 0, bypass = 0; unsigned int src_if_index; + caddr_t upper_ptr = NULL; if (hook == priv->export) { /* @@ -541,6 +647,7 @@ } NGI_GET_M(item, m); + m_old = m; /* Increase counters. */ iface->info.ifinfo_packets++; @@ -569,6 +676,22 @@ } \ } while (0) +/* +#define M_HCHECK(length) do { \ + pullup_len += length + sizeof(ip6_ext); \ + if ((m)->m_pkthdr.len < (pullup_len)) { \ + pullup_len -= length + sizeof(ip6_ext); + M_CHECK(length); + ` + } \ + if ((m)->m_len < (pullup_len) && \ + (((m) = m_pullup((m),(pullup_len))) == NULL)) { \ + error = ENOBUFS; \ + goto done; \ + } \ +} while (0) +*/ + switch (iface->info.ifinfo_dlt) { case DLT_EN10MB: /* Ethernet */ { @@ -586,6 +709,33 @@ eh = mtod(m, struct ether_header *); ip = (struct ip *)(eh + 1); break; +#ifdef INET6 + case ETHERTYPE_IPV6: + /* + * This is done not to pullup mbuf twice on every ext + * header + */ + pullup_len += sizeof(struct ip6_hdr) + sizeof(struct ip6_ext); + if (m->m_pkthdr.len >= pullup_len) { + if ((m = m_pullup(m, pullup_len)) == NULL) { + error = ENOBUFS; + goto done; + } + pullup_len -= sizeof(struct ip6_ext); + } else { + pullup_len -= sizeof(struct ip6_hdr) + sizeof(struct ip6_ext); + M_CHECK(sizeof(struct ip6_hdr)); + eh = mtod(m, struct ether_header *); + ip6 = (struct ip6_hdr *)(eh + 1); + if (ip6->ip6_nxt != IPPROTO_NONE) { + error = EINVAL; + goto bypass; + } + } + eh = mtod(m, struct ether_header *); + ip6 = (struct ip6_hdr *)(eh + 1); + break; +#endif case ETHERTYPE_VLAN: { struct ether_vlan_header *evh; @@ -597,6 +747,29 @@ M_CHECK(sizeof(struct ip)); ip = (struct ip *)(evh + 1); break; + } else if (ntohs(evh->evl_proto) == ETHERTYPE_IPV6) { +#ifdef INET6 + pullup_len += sizeof(struct ip6_hdr) + sizeof(struct ip6_ext); + if (m->m_pkthdr.len >= pullup_len) { + if ((m = m_pullup(m, pullup_len)) == NULL) { + error = ENOBUFS; + goto done; + } + pullup_len -= sizeof(struct ip6_ext); + } else { + pullup_len -= sizeof(struct ip6_hdr) + sizeof(struct ip6_ext); + M_CHECK(sizeof(struct ip6_hdr)); + eh = mtod(m, struct ether_header *); + ip6 = (struct ip6_hdr *)(eh + 1); + if (ip6->ip6_nxt != IPPROTO_NONE) { + error = EINVAL; + goto bypass; + } + } + eh = mtod(m, struct ether_header *); + ip6 = (struct ip6_hdr *)(eh + 1); + break; +#endif } } default: @@ -607,18 +780,32 @@ case DLT_RAW: /* IP packets */ M_CHECK(sizeof(struct ip)); ip = mtod(m, struct ip *); +#ifdef INET6 + if (ip->ip_v == 6) { + /* IPv6 packet */ + ip = NULL; + M_CHECK(sizeof(struct ip6_hdr)); + ip6 = mtod(m, struct ip6_hdr *); + } +#endif break; default: goto bypass; break; } - if ((ip->ip_off & htons(IP_OFFMASK)) == 0) { + if ((ip != NULL) && ((ip->ip_off & htons(IP_OFFMASK)) == 0)) { + if ((ip->ip_v != IPVERSION) || + ((ip->ip_hl << 2) < sizeof(struct ip))) + goto bypass; /* - * In case of IP header with options, we haven't pulled + * In case of IPv4 header with options, we haven't pulled * up enough, yet. */ pullup_len += (ip->ip_hl << 2) - sizeof(struct ip); + off = pullup_len; + //vlog("upper_offset = %d", off); + upper_proto = ip->ip_p; switch (ip->ip_p) { case IPPROTO_TCP: @@ -627,38 +814,161 @@ case IPPROTO_UDP: M_CHECK(sizeof(struct udphdr)); break; + case IPPROTO_SCTP: + M_CHECK(sizeof(struct sctphdr)); + break; } - } + } else if (ip != NULL) { + is_frag = 1; + upper_proto = ip->ip_p; + if ((ip->ip_v != IPVERSION) || + ((ip->ip_hl << 2) < sizeof(struct ip))) + goto bypass; + } else if (ip6 != NULL) { +#ifdef INET6 + /* Check if we can export */ + if (priv->version < NETFLOW_V9) + goto bypass; + + /* Loop thru IPv6 extended headers to get upper layer header / frag */ + int cur = ip6->ip6_nxt, hdr_off = 0; + struct ip6_ext *ip6e; + struct ip6_frag *ip6f; + + off = pullup_len; + upper_proto = cur; + + if ((ip6->ip6_vfc & IPV6_VERSION_MASK) != IPV6_VERSION) + goto bypass; + + while (42) { + + /* + * At the moment we're 'standing' with pullup_len and + * off + */ + switch (cur) { + + /* Ensure pointer is contiguous */ + case IPPROTO_TCP: + M_CHECK(sizeof(struct tcphdr)); + goto loopend; + case IPPROTO_UDP: + M_CHECK(sizeof(struct udphdr)); + goto loopend; + case IPPROTO_SCTP: + M_CHECK(sizeof(struct sctphdr)); + goto loopend; + + /* Loop until 'real' upper layer headers */ + case IPPROTO_HOPOPTS: + case IPPROTO_ROUTING: + case IPPROTO_DSTOPTS: + ip6e = (struct ip6_ext *)(mtod(m, caddr_t) + off); + upper_proto = ip6e->ip6e_nxt; + hdr_off = (ip6e->ip6e_len + 1) << 3; + break; - switch (iface->info.ifinfo_dlt) { - case DLT_EN10MB: - { - struct ether_header *eh; + /* RFC4302, can be before DSTOPTS */ + case IPPROTO_AH: + ip6e = (struct ip6_ext *)(mtod(m, caddr_t) + off); + upper_proto = ip6e->ip6e_nxt; + hdr_off = (ip6e->ip6e_len + 2) << 2; + break; - eh = mtod(m, struct ether_header *); - switch (ntohs(eh->ether_type)) { - case ETHERTYPE_IP: - ip = (struct ip *)(eh + 1); - break; - case ETHERTYPE_VLAN: - { - struct ether_vlan_header *evh; + + case IPPROTO_FRAGMENT: + ip6f = (struct ip6_frag *)(mtod(m, caddr_t) + off); + upper_proto = ip6f->ip6f_nxt; + hdr_off = sizeof(struct ip6_frag); + off += hdr_off; + is_frag = 1; + goto loopend; + +/* + case IPPROTO_NONE: + goto loopend; +*/ + default: + goto loopend; + } - evh = mtod(m, struct ether_vlan_header *); - ip = (struct ip *)(evh + 1); + off += hdr_off + sizeof(struct ip6_ext); + cur = upper_proto; + if (m->m_pkthdr.len >= off) { + if ((m = m_pullup(m, off)) == NULL) { + error = ENOBUFS; + goto done; + } + off -= sizeof(struct ip6_ext); + pullup_len += hdr_off; + } else { + /* + * Packet ends somewhere here. + * if its next header is not IPPROTO_NONE it is + * possibly mailformed packet. Let's count as RAW IP + */ + upper_proto = IPPROTO_NONE; + off -= sizeof(struct ip6_ext); + goto loopend; + } + + } +#endif + } + +#ifdef INET6 +loopend: +#endif + if (m != m_old) { + switch (iface->info.ifinfo_dlt) { + case DLT_EN10MB: /* Ethernet */ + { + struct ether_header *eh; + + eh = mtod(m, struct ether_header *); + switch (ntohs(eh->ether_type)) { + case ETHERTYPE_IP: + ip = (struct ip *)(eh + 1); + break; + case ETHERTYPE_IPV6: + ip6 = (struct ip6_hdr *)(eh + 1); + break; + case ETHERTYPE_VLAN: + { + struct ether_vlan_header *evh; + + evh = mtod(m, struct ether_vlan_header *); + if (ntohs(evh->evl_proto) == ETHERTYPE_IP) { + ip = (struct ip *)(evh + 1); + break; + } else if (ntohs(evh->evl_proto) == ETHERTYPE_IPV6) { +#ifdef INET6 + ip6 = (struct ip6_hdr *)(evh + 1); + break; +#endif + } + } + default: + panic("ng_netflow entered deadcode"); + } + break; + } + case DLT_RAW: /* IP packets */ + ip = mtod(m, struct ip *); +#ifdef INET6 + if (ip->ip_v == 6) { + /* IPv6 packet */ + ip = NULL; + ip6 = mtod(m, struct ip6_hdr *); + } +#endif break; - } default: panic("ng_netflow entered deadcode"); } - break; - } - case DLT_RAW: - ip = mtod(m, struct ip *); - break; - default: - panic("ng_netflow entered deadcode"); } + upper_ptr = (caddr_t)(mtod(m, caddr_t) + off); #undef M_CHECK @@ -670,7 +980,7 @@ } else src_if_index = iface->info.ifinfo_index; - error = ng_netflow_flow_add(priv, ip, src_if_index); + error = ng_netflow_flow_add(priv, (ip != NULL) ? (caddr_t)ip : (caddr_t)ip6, upper_ptr, upper_proto, is_frag, src_if_index); bypass: if (out != NULL) { diff -urN sys/netgraph/_netflow.orig/netflow.h sys/netgraph/netflow/netflow.h --- sys/netgraph/_netflow.orig/netflow.h 2009-09-01 02:37:44.000000000 +0400 +++ sys/netgraph/netflow/netflow.h 2009-09-06 12:41:29.000000000 +0400 @@ -46,6 +46,7 @@ #define NETFLOW_V1 1 #define NETFLOW_V5 5 +#define NETFLOW_V9 9 struct netflow_v1_header { @@ -69,6 +70,16 @@ uint16_t pad; /* Pad to word boundary */ } __attribute__((__packed__)); +struct netflow_v9_header +{ + uint16_t version; /* NetFlow version */ + uint16_t count; /* Total number of records in packet */ + uint32_t sys_uptime; /* System uptime */ + uint32_t unix_secs; /* Current seconds since 0000 UTC 1970 */ + uint32_t seq_num; /* Sequence number */ + uint32_t source_id; /* Observation Domain id */ +} __attribute__((__packed__)); + struct netflow_v1_record { uint32_t src_addr; /* Source IP address */ @@ -115,6 +126,142 @@ uint16_t pad2; /* Pad to word boundary */ } __attribute__((__packed__)); + + +/* RFC3954 field definitions */ +#define NETFLOW_V9_FIELD_IN_BYTES 1 /* Input bytes count for a flow. Default 4, can be 8 */ +#define NETFLOW_V9_FIELD_IN_PKTS 2 /* Incoming counter with number of packets associated with an IP Flow. Default 4 */ +#define NETFLOW_V9_FIELD_FLOWS 3 /* Number of Flows that were aggregated. Default 4 */ +#define NETFLOW_V9_FIELD_PROTOCOL 4 /* IP protocol byte. 1 */ +#define NETFLOW_V9_FIELD_TOS 5 /* Type of service byte setting when entering the incoming interface. 1 */ +#define NETFLOW_V9_FIELD_TCP_FLAGS 6 /* TCP flags; cumulative of all the TCP flags seen in this Flow. 1 */ +#define NETFLOW_V9_FIELD_L4_SRC_PORT 7 /* TCP/UDP source port number. 2 */ +#define NETFLOW_V9_FIELD_IPV4_SRC_ADDR 8 /* IPv4 source address. 4 */ +#define NETFLOW_V9_FIELD_SRC_MASK 9 /* The number of contiguous bits in the source subnet mask (i.e., the mask in slash notation). 1 */ +#define NETFLOW_V9_FIELD_INPUT_SNMP 10 /* Input interface index. Default 2 */ +#define NETFLOW_V9_FIELD_L4_DST_PORT 11 /* TCP/UDP destination port number. 2 */ +#define NETFLOW_V9_FIELD_IPV4_DST_ADDR 12 /* IPv4 destination address. 4 */ +#define NETFLOW_V9_FIELD_DST_MASK 13 /* The number of contiguous bits in the destination subnet mask (i.e., the mask in slash notation). 1 */ +#define NETFLOW_V9_FIELD_OUTPUT_SNMP 14 /* Output interface index. Default 2 */ +#define NETFLOW_V9_FIELD_IPV4_NEXT_HOP 15 /* IPv4 address of the next-hop router. 4 */ +#define NETFLOW_V9_FIELD_SRC_AS 16 /* Source BGP autonomous system number. Default 2, can be 4 */ +#define NETFLOW_V9_FIELD_DST_AS 17 /* Destination BGP autonomous system number. Default 2, can be 4 */ +#define NETFLOW_V9_FIELD_BGP_IPV4_NEXT_HOP 18 /* Next-hop router's IP address in the BGP domain. 4 */ +#define NETFLOW_V9_FIELD_MUL_DST_PKTS 19 /* IP multicast outgoing packet counter for packets associated with IP flow. Default 4 */ +#define NETFLOW_V9_FIELD_MUL_DST_BYTES 20 /* IP multicast outgoing Octet (byte) counter for the number of bytes associated with IP flow. Default 4 */ +#define NETFLOW_V9_FIELD_LAST_SWITCHED 21 /* sysUptime in msec at which the last packet of this Flow was switched. 4 */ +#define NETFLOW_V9_FIELD_FIRST_SWITCHED 22 /* sysUptime in msec at which the first packet of this Flow was switched. 4 */ +#define NETFLOW_V9_FIELD_OUT_BYTES 23 /* Outgoing counter for the number of bytes associated with an IP Flow. Default 4 */ +#define NETFLOW_V9_FIELD_OUT_PKTS 24 /* Outgoing counter for the number of packets associated with an IP Flow. Default 4 */ +#define NETFLOW_V9_FIELD_IPV6_SRC_ADDR 27 /* IPv6 source address. 16 */ +#define NETFLOW_V9_FIELD_IPV6_DST_ADDR 28 /* IPv6 destination address. 16 */ +#define NETFLOW_V9_FIELD_IPV6_SRC_MASK 29 /* Length of the IPv6 source mask in contiguous bits. 1 */ +#define NETFLOW_V9_FIELD_IPV6_DST_MASK 30 /* Length of the IPv6 destination mask in contiguous bits. 1 */ +#define NETFLOW_V9_FIELD_IPV6_FLOW_LABEL 31 /* IPv6 flow label as per RFC 2460 definition. 3 */ +#define NETFLOW_V9_FIELD_ICMP_TYPE 32 /* Internet Control Message Protocol (ICMP) packet type; reported as ICMP Type * 256 + ICMP code. 2 */ +#define NETFLOW_V9_FIELD_MUL_IGMP_TYPE 33 /* Internet Group Management Protocol (IGMP) packet type. 1 */ +#define NETFLOW_V9_FIELD_SAMPLING_INTERVAL 34 /* When using sampled NetFlow, the rate at which packets are sampled; for example, a value of 100 indicates that one of every hundred packets is sampled. 4 */ +#define NETFLOW_V9_FIELD_SAMPLING_ALGORITHM 35 /* For sampled NetFlow platform-wide: 0x01 deterministic sampling 0x02 random sampling. 1 */ +#define NETFLOW_V9_FIELD_FLOW_ACTIVE_TIMEOUT 36 /* Timeout value (in seconds) for active flow entries in the NetFlow cache. 2 */ +#define NETFLOW_V9_FIELD_FLOW_INACTIVE_TIMEOUT 37 /* Timeout value (in seconds) for inactive Flow entries in the NetFlow cache. 2 */ +#define NETFLOW_V9_FIELD_ENGINE_TYPE 38 /* Type of Flow switching engine (route processor, linecard, etc...). 1 */ +#define NETFLOW_V9_FIELD_ENGINE_ID 39 /* ID number of the Flow switching engine. 1 */ +#define NETFLOW_V9_FIELD_TOTAL_BYTES_EXP 40 /* Counter with for the number of bytes exported by the Observation Domain. Default 4 */ +#define NETFLOW_V9_FIELD_TOTAL_PKTS_EXP 41 /* Counter with for the number of packets exported by the Observation Domain. Default 4 */ +#define NETFLOW_V9_FIELD_TOTAL_FLOWS_EXP 42 /* Counter with for the number of flows exported by the Observation Domain. Default 4 */ +#define NETFLOW_V9_FIELD_MPLS_TOP_LABEL_TYPE 46 /* MPLS Top Label Type. 1 */ +#define NETFLOW_V9_FIELD_MPLS_TOP_LABEL_IP_ADDR 47 /* Forwarding Equivalent Class corresponding to the MPLS Top Label. 4 */ +#define NETFLOW_V9_FIELD_FLOW_SAMPLER_ID 48 /* Identifier shown in "show flow-sampler". 1 */ +#define NETFLOW_V9_FIELD_FLOW_SAMPLER_MODE 49 /* The type of algorithm used for sampling data. 2 */ +#define NETFLOW_V9_FIELD_FLOW_SAMPLER_RANDOM_INTERVAL 50 /* Packet interval at which to sample. 4. */ +#define NETFLOW_V9_FIELD_DST_TOS 55 /* Type of Service byte setting when exiting outgoing interface. 1. */ +#define NETFLOW_V9_FIELD_SRC_MAC 56 /* Source MAC Address. 6 */ +#define NETFLOW_V9_FIELD_DST_MAC 57 /* Destination MAC Address. 6 */ +#define NETFLOW_V9_FIELD_SRC_VLAN 58 /* Virtual LAN identifier associated with ingress interface. 2 */ +#define NETFLOW_V9_FIELD_DST_VLAN 59 /* irtual LAN identifier associated with egress interface. 2 */ +#define NETFLOW_V9_FIELD_IP_PROTOCOL_VERSION 60 /* Internet Protocol Version. Set to 4 for IPv4, set to 6 for IPv6. If not present in the template, then version 4 is assumed. 1. */ +#define NETFLOW_V9_FIELD_DIRECTION 61 /* Flow direction: 0 - ingress flow 1 - egress flow. 1 */ +#define NETFLOW_V9_FIELD_IPV6_NEXT_HOP 62 /* IPv6 address of the next-hop router. 16 */ +#define NETFLOW_V9_FIELD_BGP_IPV6_NEXT_HOP 63 /* Next-hop router in the BGP domain. 16 */ +#define NETFLOW_V9_FIELD_IPV6_OPTION_HEADERS 64 /* Bit-encoded field identifying IPv6 option headers found in the flow */ +#define NETFLOW_V9_FIELD_MPLS_LABEL_1 70 /* MPLS label at position 1 in the stack. 3 */ +#define NETFLOW_V9_FIELD_MPLS_LABEL_2 71 /* MPLS label at position 2 in the stack. 3 */ +#define NETFLOW_V9_FIELD_MPLS_LABEL_3 72 /* MPLS label at position 3 in the stack. 3 */ +#define NETFLOW_V9_FIELD_MPLS_LABEL_4 73 /* MPLS label at position 4 in the stack. 3 */ +#define NETFLOW_V9_FIELD_MPLS_LABEL_5 74 /* MPLS label at position 5 in the stack. 3 */ +#define NETFLOW_V9_FIELD_MPLS_LABEL_6 75 /* MPLS label at position 6 in the stack. 3 */ +#define NETFLOW_V9_FIELD_MPLS_LABEL_7 76 /* MPLS label at position 7 in the stack. 3 */ +#define NETFLOW_V9_FIELD_MPLS_LABEL_8 77 /* MPLS label at position 8 in the stack. 3 */ +#define NETFLOW_V9_FIELD_MPLS_LABEL_9 78 /* MPLS label at position 9 in the stack. 3 */ +#define NETFLOW_V9_FIELD_MPLS_LABEL_10 79 /* MPLS label at position 10 in the stack. 3 */ + +#ifdef COUNTERS_64 +#define cntr uint64_t +#define cntr_max UINT64_MAX +#else +#define cntr uint32_t +#define cntr_max UINT_MAX +#endif + +struct netflow_v9_template +{ + int field_id; + int field_length; +}; + +/* Template ID for tcp/udp v4 streams ID:257 (0x100 + NETFLOW_V9_FLOW_V4_L4) */ +struct netflow_v9_record_ipv4_tcp +{ + uint32_t src_addr; /* Source IPv4 address (IPV4_SRC_ADDR) */ + uint32_t dst_addr; /* Destination IPv4 address (IPV4_DST_ADDR) */ + uint32_t next_hop; /* Next hop IPv4 address (IPV4_NEXT_HOP) */ + uint16_t i_ifx; /* Source interface index (INPUT_SNMP) */ + uint16_t o_ifx; /* Destination interface index (OUTPUT_SNMP) */ + cntr i_packets; /* Number of incoming packets in a flow (IN_PKTS) */ + cntr i_octets; /* Number of incoming octets in a flow (IN_BYTES) */ + cntr o_packets; /* Number of outgoing packets in a flow (OUT_PKTS) */ + cntr o_octets; /* Number of outgoing octets in a flow (OUT_BYTES) */ + uint32_t first; /* System uptime at start of a flow (FIRST_SWITCHED) */ + uint32_t last; /* System uptime at end of a flow (LAST_SWITCHED) */ + uint16_t s_port; /* Source port (L4_SRC_PORT) */ + uint16_t d_port; /* Destination port (L4_DST_PORT) */ + uint8_t flags; /* Cumulative OR of tcp flags (TCP_FLAGS) */ + uint8_t prot; /* IP protocol */ + uint8_t tos; /* IP type of service IN (or OUT) (TOS) */ + uint32_t src_as; /* Src peer/origin Autonomous System (SRC_AS) */ + uint32_t dst_as; /* Dst peer/origin Autonomous System (DST_AS) */ + uint8_t src_mask; /* Source route's mask bits (SRC_MASK) */ + uint8_t dst_mask; /* Destination route's mask bits (DST_MASK) */ +} __attribute__((__packed__)); + + +/* Template ID for tcp/udp v6 streams ID: 260 (0x100 + NETFLOW_V9_FLOW_V6_L4) */ +struct netflow_v9_record_ipv6_tcp +{ + struct in6_addr src_addr; /* Source IPv6 address (IPV6_SRC_ADDR) */ + struct in6_addr dst_addr; /* Destination IPv6 address (IPV6_DST_ADDR) */ + struct in6_addr next_hop; /* Next hop IPv6 address (IPV6_NEXT_HOP) */ + uint16_t i_ifx; /* Source interface index (INPUT_SNMP) */ + uint16_t o_ifx; /* Destination interface index (OUTPUT_SNMP) */ + cntr i_packets; /* Number of incoming packets in a flow (IN_PKTS) */ + cntr i_octets; /* Number of incoming octets in a flow (IN_BYTES) */ + cntr o_packets; /* Number of outgoing packets in a flow (OUT_PKTS) */ + cntr o_octets; /* Number of outgoing octets in a flow (OUT_BYTES) */ + uint32_t first; /* System uptime at start of a flow (FIRST_SWITCHED) */ + uint32_t last; /* System uptime at end of a flow (LAST_SWITCHED) */ + uint16_t s_port; /* Source port (L4_SRC_PORT) */ + uint16_t d_port; /* Destination port (L4_DST_PORT) */ + uint8_t flags; /* Cumulative OR of tcp flags (TCP_FLAGS) */ + uint8_t prot; /* IP protocol */ + uint8_t tos; /* IP type of service IN (or OUT) (TOS) */ + uint32_t src_as; /* Src peer/origin Autonomous System (SRC_AS) */ + uint32_t dst_as; /* Dst peer/origin Autonomous System (DST_AS) */ + uint8_t src_mask; /* Source route's mask bits (SRC_MASK) */ + uint8_t dst_mask; /* Destination route's mask bits (DST_MASK) */ +} __attribute__((__packed__)); + +#define vlog(x, ...) log(LOG_DEBUG, "%s:%d " x "\n", __FUNCTION__, __LINE__, ##__VA_ARGS__) + #define NETFLOW_V1_MAX_RECORDS 24 #define NETFLOW_V5_MAX_RECORDS 30 @@ -123,7 +270,50 @@ #define NETFLOW_V5_MAX_SIZE (sizeof(netflow_v5_header)+ \ sizeof(netflow_v5_record)*NETFLOW_V5_MAX_RECORDS) +#define BASE_MTU 1500 +#define MIN_MTU sizeof(struct netflow_v5_header) +#define MAX_MTU 16384 +#define NETFLOW_V9_MAX_SIZE _NETFLOW_V9_MAX_SIZE(BASE_MTU) +#define _NETFLOW_V9_MAX_SIZE(x) (x) - sizeof(struct ip6_hdr) - sizeof(struct udphdr) +#define NETFLOW_V9_MAX_FLOWSETS 2 + +#define NETFLOW_V9_MAX_RECORD_SIZE sizeof(struct netflow_v9_record_ipv6_tcp) +#define NETFLOW_V9_MAX_PACKETS_TEMPL 500 /* Send data templates every ... packets */ +#define NETFLOW_V9_MAX_TIME_TEMPL 600 /* Send data templates every ... seconds */ +#define NETFLOW_V9_MAX_TEMPLATES 16 /* Not a real value */ +#define _NETFLOW_V9_TEMPLATE_SIZE(x) (sizeof(x) / sizeof(struct netflow_v9_template)) * 4 +//#define _NETFLOW_V9_TEMPLATE_SIZE(x) ((x) + 1) * 4 + +/* Flow Templates */ +#define NETFLOW_V9_FLOW_V4_L4 1 /* IPv4 TCP/UDP packet */ +#define NETFLOW_V9_FLOW_V4_ICMP 2 /* IPv4 ICMP packet, currently unused */ +#define NETFLOW_V9_FLOW_V4_L3 3 /* IPv4 IP packet */ +#define NETFLOW_V9_FLOW_V6_L4 4 /* IPv6 TCP/UDP packet */ +#define NETFLOW_V9_FLOW_V6_ICMP 5 /* IPv6 ICMP packet, currently unused */ +#define NETFLOW_V9_FLOW_V6_L3 6 /* IPv6 IP packet */ + +#define NETFLOW_V9_FLOW_FAKE 65535 /* Not uset used in real flowsets! */ + struct netflow_v5_export_dgram { struct netflow_v5_header header; struct netflow_v5_record r[NETFLOW_V5_MAX_RECORDS]; } __attribute__((__packed__)); + +struct netflow_v9_export_dgram { + struct netflow_v9_header header; + char data; /* MTU can change, record length is dynamic */ +}; + +struct netflow_v9_flowset_header { + uint16_t id; /* FlowSet id */ + uint16_t length; /* FlowSet length */ +} __attribute__((__packed__)); + +struct netflow_v9_mbuf_tag { + struct m_tag tag; /* pointer to mbuf tag */ + uint16_t length; /* Current packet length */ + uint16_t count; /* current records count */ + uint16_t mtu; /* max MTU shapshot */ + uint16_t flow_type; /* current flowset */ + uint16_t flow_header; /* offset pointing to current flow header */ +}; diff -urN sys/netgraph/_netflow.orig/ng_netflow.h sys/netgraph/netflow/ng_netflow.h --- sys/netgraph/_netflow.orig/ng_netflow.h 2009-09-01 02:37:44.000000000 +0400 +++ sys/netgraph/netflow/ng_netflow.h 2009-09-06 16:36:17.000000000 +0400 @@ -51,6 +51,9 @@ NGM_NETFLOW_SETIFINDEX = 5, /* set interface index */ NGM_NETFLOW_SETTIMEOUTS = 6, /* set active/inactive flow timeouts */ NGM_NETFLOW_SETCONFIG = 7, /* set flow generation options */ + NGM_NETFLOW_SETVERSION = 8, /* set flow export version */ + NGM_NETFLOW_SETTEMPLATEPERIODIC = 9, /* set v9 flow template periodic */ + NGM_NETFLOW_SETMTU = 10, /* set outgoing interface MTU */ }; /* This structure is returned by the NGM_NETFLOW_INFO message */ @@ -105,10 +108,34 @@ u_int32_t conf; /* new config */ }; +/* This structure is passed to NGM_NETFLOW_SETVERSION */ +struct ng_netflow_setversion { + u_int8_t version; /* netflow version */ +}; + +/* This structure is passed to NGM_NETFLOW_SETTEMPLATEPERIODIC */ +struct ng_netflow_settemplateperiodic { + u_int16_t time; /* max time between announce */ + u_int16_t packets; /* max packets between announce */ +}; + +/* This structure is passed to NGM_NETFLOW_SETMTU */ +struct ng_netflow_setmtu { + u_int16_t mtu; /* MTU for packet */ +}; + /* This is unique data, which identifies flow */ struct flow_rec { - struct in_addr r_src; - struct in_addr r_dst; + uint16_t flow_type; /* IPv4 L4/L3 Ipv6 L4/L3 flow, see NETFLOW_V9_FLOW* */ + uint16_t ether_proto; /* unused */ + union { + struct in_addr r_src; + struct in6_addr r_src6; + } src; + union { + struct in_addr r_dst; + struct in6_addr r_dst6; + } dst; union { struct { uint16_t s_port; /* source TCP/UDP port */ @@ -137,7 +164,10 @@ /* A flow entry which accumulates statistics */ struct flow_entry_data { struct flow_rec r; - struct in_addr next_hop; + union { + struct in_addr next_hop; + struct in6_addr next_hop6; + } n; uint16_t fle_o_ifx; /* output interface index */ #define fle_i_ifx r.misc.i.i_ifx uint8_t dst_mask; /* destination route mask bits */ @@ -146,6 +176,7 @@ u_long bytes; long first; /* uptime on first packet */ long last; /* uptime on last packet */ + uint16_t proto; /* IP/IPv6 */ u_char tcp_flags; /* cumulative OR */ }; @@ -227,6 +258,26 @@ { NULL } \ } +/* Parse the setversion structure */ +#define NG_NETFLOW_SETVERSION_TYPE { \ + { "version", &ng_parse_uint8_type }, \ + { NULL } \ +} + +/* Parse the settemplateperiodic structure */ +#define NG_NETFLOW_SETTEMPLATEPERIODIC_TYPE { \ + { "time", &ng_parse_uint16_type }, \ + { "packets", &ng_parse_uint16_type }, \ + { NULL } \ +} + +/* Parse the setmtu structure */ +#define NG_NETFLOW_SETMTU_TYPE { \ + { "mtu", &ng_parse_uint16_type }, \ + { NULL } \ +} + + /* Private hook data */ struct ng_netflow_iface { hook_p hook; /* NULL when disconnected */ @@ -270,6 +321,20 @@ item_p export_item; struct mtx export_mtx; uint32_t flow_seq; /* current flow sequence */ + /* + * RFC 3954 clause 7.3 + * "Both options MUST be configurable by the user on the Exporter." + */ + uint16_t templ_time; /* time between sending templates */ + uint16_t templ_packets; /* packets between sending templates */ + uint32_t templ_last_ts; /* unixtime of last template announce */ + uint32_t templ_last_pkt; /* packets count on last template announce */ + uint32_t sent_packets; /* packets sent by exporeter; can be reached another way ? */ + u_char version; /* Netflow export version */ + u_char flowsets_count; /* current flowsets used */ + u_char flowset_records[NETFLOW_V9_MAX_FLOWSETS - 1]; /* Count of records in each flowset */ + uint16_t mtu; /* export interface MTU */ + struct netflow_v9_flowset_header *v9_flowsets[NETFLOW_V9_MAX_FLOWSETS - 1]; /* Pointers to pre-compiled flowsets */ struct ng_netflow_iface ifaces[NG_NETFLOW_MAXIFACES]; }; @@ -286,14 +351,15 @@ #define MTAG_NETFLOW 1221656444 #define MTAG_NETFLOW_CALLED 0 +#define MTAG_NETFLOW_V9 1 /* Prototypes for netflow.c */ int ng_netflow_cache_init(priv_p); void ng_netflow_cache_flush(priv_p); void ng_netflow_copyinfo(priv_p, struct ng_netflow_info *); timeout_t ng_netflow_expire; -int ng_netflow_flow_add(priv_p, struct ip *, unsigned int src_if_index); +int ng_netflow_flow_add(priv_p, caddr_t ip_ptr, caddr_t upper_ptr, uint8_t upper_proto, uint8_t is_frag, unsigned int src_if_index); int ng_netflow_flow_show(priv_p, uint32_t last, struct ng_mesg *); - +void ng_netflow_switch_version(priv_p priv, int ver, int boot); #endif /* _KERNEL */ #endif /* _NG_NETFLOW_H_ */ diff -urN sys/modules/netgraph/netflow/Makefile.orig sys/modules/netgraph/netflow/Makefile --- sys/modules/netgraph/netflow/Makefile.orig 2009-09-06 16:31:18.000000000 +0400 +++ sys/modules/netgraph/netflow/Makefile 2009-09-06 16:33:32.000000000 +0400 @@ -3,9 +3,19 @@ # Author: Gleb Smirnoff # +.include + .PATH: ${.CURDIR}/../../../netgraph/netflow KMOD= ng_netflow -SRCS= ng_netflow.c netflow.c +SRCS= ng_netflow.c netflow.c opt_inet6.h + +.if !defined(KERNBUILDDIR) + +.if ${MK_INET6_SUPPORT} != "no" +opt_inet6.h: + echo "#define INET6 1" > ${.TARGET} +.endif +.endif .include --------------010607050501030003050405-- From owner-freebsd-net@FreeBSD.ORG Sun Sep 6 22:31:53 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 453DF106566B; Sun, 6 Sep 2009 22:31:53 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by mx1.freebsd.org (Postfix) with ESMTP id 9F5718FC08; Sun, 6 Sep 2009 22:31:52 +0000 (UTC) Received: by ewy4 with SMTP id 4so433236ewy.36 for ; Sun, 06 Sep 2009 15:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=sutaW3IPsfV3eys2+pVWlFqLpUnQfD8zn1Z8gPCXNog=; b=BtjNLnwqoBYhHiB4hkvApoioAS8G7+ZHzdM68wveZp5mx/ik876C9yy+8XSAh0OwPk 0ilg4Rklc9DI2SssxT7F7jQtIDuWshoFtjuf7yEY1dFlHIAvBt2fx3hVJhK3tHuh7Kro Nnmk8CtLz54+OAUogncF4EPcogbRd+9s1sK9A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=r5fKkDA/0on5BmEp88YiMvwY/+/m13sQ5QbHBCCpttZ/xrh+hqRRxeICl6ZWYvJWvs +1tWiF9ZjhpM+LxGb0i4u80Xv/CZhd4BXhuVI8CGrHL22LhFqebzaZmIZiJZOjeJfNvI vqZ82zTwAIUhMz/1QZog0Wj4XtcRK6RLS/QRA= MIME-Version: 1.0 Received: by 10.211.154.17 with SMTP id g17mr864569ebo.32.1252275070144; Sun, 06 Sep 2009 15:11:10 -0700 (PDT) Date: Sun, 6 Sep 2009 18:11:10 -0400 Message-ID: From: grarpamp To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-isp@freebsd.org Subject: Call for testers: ng_netflow with v9 and IPv6 support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 22:31:53 -0000 Wouldn't it be better to support the obvious formal emergent standards track protocol instead of the legacy informational one? Or to perform both via sysctl or other arguments/defines, with the standard IPFIX being the default mode? Have you reviewed the nProbe code for other various ideas? Thanks for working on netflow :) And any form of v6 is good to have finally. ========================================================================= Network Working Group B. Claise, Ed. Request for Comments: 5101 Cisco Systems, Inc. Category: Standards Track January 2008 Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information This document specifies an Internet standards track protocol for the Internet community Network Working Group J. Quittek Request for Comments: 5102 NEC Category: Standards Track S. Bryant B. Claise P. Aitken Cisco Systems, Inc. J. Meyer PayPal January 2008 Information Model for IP Flow Information Export This document specifies an Internet standards track protocol for the Internet community Network Working Group B. Trammell Request for Comments: 5103 CERT/NetSA Category: Standards Track E. Boschi Hitachi Europe January 2008 Bidirectional Flow Export Using IP Flow Information Export (IPFIX) This document specifies an Internet standards track protocol for the Internet community Network Working Group E. Boschi Request for Comments: 5153 Hitachi Europe Category: Informational L. Mark Fraunhofer FOKUS J. Quittek M. Stiemerling NEC P. Aitken Cisco Systems, Inc. April 2008 IP Flow Information Export (IPFIX) Implementation Guidelines This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Network Working Group S. Leinen Request for Comments: 3955 SWITCH Category: Informational October 2004 Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX) This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Network Working Group J. Quittek Request for Comments: 3917 NEC Europe Ltd. Category: Informational T. Zseby Fraunhofer FOKUS B. Claise Cisco Systems S. Zander Swinburne University October 2004 Requirements for IP Flow Information Export (IPFIX) This memo provides information for the Internet community. It does not specify an Internet standard of any kind. And others... ========================================================================= Network Working Group B. Claise, Ed. Request for Comments: 3954 Cisco Systems Category: Informational October 2004 Cisco Systems NetFlow Services Export Version 9 This RFC documents the NetFlow services export protocol Version 9 as it was when submitted to the IETF as a basis for further work in the IPFIX WG. This RFC itself is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose... And others... ========================================================================= From owner-freebsd-net@FreeBSD.ORG Mon Sep 7 01:25:25 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D06F2106566B for ; Mon, 7 Sep 2009 01:25:25 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outD.internet-mail-service.net (outd.internet-mail-service.net [216.240.47.227]) by mx1.freebsd.org (Postfix) with ESMTP id B59B38FC17 for ; Mon, 7 Sep 2009 01:25:25 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 74522B98AB; Sun, 6 Sep 2009 18:25:25 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id CD7E42D6006; Sun, 6 Sep 2009 18:25:24 -0700 (PDT) Message-ID: <4AA46103.9000108@elischer.org> Date: Sun, 06 Sep 2009 18:25:23 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: grarpamp References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-isp@freebsd.org, freebsd-net@freebsd.org Subject: Re: Call for testers: ng_netflow with v9 and IPv6 support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 01:25:25 -0000 grarpamp wrote: > Wouldn't it be better to support the obvious formal emergent standards > track protocol instead of the legacy informational one? Or to perform > both via sysctl or other arguments/defines, with the standard IPFIX > being the default mode? Have you reviewed the nProbe code for other > various ideas? Thanks for working on netflow :) And any form of v6 > is good to have finally. if you have time it sounds like you know enough about it to be useful.. get involved :-) > > ========================================================================= > > Network Working Group B. Claise, Ed. > Request for Comments: 5101 Cisco Systems, Inc. > Category: Standards Track January 2008 > Specification of the IP Flow Information Export (IPFIX) Protocol > for the Exchange of IP Traffic Flow Information > This document specifies an Internet standards track protocol for the > Internet community > > > Network Working Group J. Quittek > Request for Comments: 5102 NEC > Category: Standards Track S. Bryant > B. Claise > P. Aitken > Cisco Systems, Inc. > J. Meyer > PayPal > January 2008 > Information Model for IP Flow Information Export > This document specifies an Internet standards track protocol for the > Internet community > > > Network Working Group B. Trammell > Request for Comments: 5103 CERT/NetSA > Category: Standards Track E. Boschi > Hitachi Europe > January 2008 > Bidirectional Flow Export Using IP Flow Information Export (IPFIX) > This document specifies an Internet standards track protocol for the > Internet community > > > Network Working Group E. Boschi > Request for Comments: 5153 Hitachi Europe > Category: Informational L. Mark > Fraunhofer FOKUS > J. Quittek > M. Stiemerling > NEC > P. Aitken > Cisco Systems, Inc. > April 2008 > IP Flow Information Export (IPFIX) Implementation Guidelines > This memo provides information for the Internet community. It does > not specify an Internet standard of any kind. > > > Network Working Group S. Leinen > Request for Comments: 3955 SWITCH > Category: Informational October 2004 > Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX) > This memo provides information for the Internet community. It does > not specify an Internet standard of any kind. > > > Network Working Group J. Quittek > Request for Comments: 3917 NEC Europe Ltd. > Category: Informational T. Zseby > Fraunhofer FOKUS > B. Claise > Cisco Systems > S. Zander > Swinburne University > October 2004 > Requirements for IP Flow Information Export (IPFIX) > This memo provides information for the Internet community. It does > not specify an Internet standard of any kind. > > > And others... > > ========================================================================= > > Network Working Group B. Claise, Ed. > Request for Comments: 3954 Cisco Systems > Category: Informational October 2004 > Cisco Systems NetFlow Services Export Version 9 > This RFC documents the NetFlow services export protocol Version 9 as > it was when submitted to the IETF as a basis for further work in the > IPFIX WG. > This RFC itself is not a candidate for any level of Internet > Standard. The IETF disclaims any knowledge of the fitness of this > RFC for any purpose... > > And others... > > ========================================================================= > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Sep 7 11:07:05 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AFF410656C7 for ; Mon, 7 Sep 2009 11:07:05 +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 EC84C8FC22 for ; Mon, 7 Sep 2009 11:07:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n87B74nO010321 for ; Mon, 7 Sep 2009 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n87B74p7010317 for freebsd-net@FreeBSD.org; Mon, 7 Sep 2009 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 7 Sep 2009 11:07:04 GMT Message-Id: <200909071107.n87B74p7010317@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 11:07:05 -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/138427 net [wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138390 net [gif] [patch] NULL pointer dereference in gif_input() o kern/138378 net [altq] [patch] Memory leak in hfsc_class_modify() in f o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR on 8.0-BE o kern/138292 net [zyd] [usb8] "zyd0: device timeout" with ZyXEL G-202 o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138130 net [netinet] [patch] Resource leak in LibAliasRefreshModu o kern/138046 net [tcp] tcp sockets stay in SYN_SENT even after receivin o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed o kern/137795 net [sctp] [panic] mtx_lock() of destroyed mutex o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137317 net [tcp] logs full of syncache problems o kern/137292 net [ste] DFE-580TX not working properly o kern/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137170 net [ath] atheros AR9285 not recognised o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136482 net [age] Attansic L1 Gigabit Ethernet recieves multicasts o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135836 net [bce] bce BCM5709 Watchdog after warm boot - ok after o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/135067 net [patch] [fib] Incorrect KASSERTs in sys/net/route.c o kern/134956 net [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se o kern/134931 net [route] [fib] Route messages sent to all socket listen o kern/134658 net [bce] bce driver fails on PowerEdge m610 blade. o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134369 net [route] [ip6] IPV6 in Head broken for routing table up o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132625 net [iwn] iwn drivers don't support setting country o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o conf/132179 net [patch] /etc/network.subr: ipv6 rtsol on incorrect wla o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 335 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Sep 7 11:40:17 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32232106566C for ; Mon, 7 Sep 2009 11:40:17 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (unknown [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id C1DEC8FC14 for ; Mon, 7 Sep 2009 11:40:16 +0000 (UTC) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 5F3EE153437; Mon, 7 Sep 2009 13:40:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYOK8QbMBQ05; Mon, 7 Sep 2009 13:40:13 +0200 (CEST) Received: from [212.61.27.67] (opteron [212.61.27.67]) by mail.digiware.nl (Postfix) with ESMTP id 49197153436; Mon, 7 Sep 2009 13:40:13 +0200 (CEST) Message-ID: <4AA4F11C.4060200@digiware.nl> Date: Mon, 07 Sep 2009 13:40:12 +0200 From: Willem Jan Withagen Organization: Digiware User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Manish Vachharajani References: <4AA14018.3010102@digiware.nl> <5bc218350909041002x670460c8nf202a714182d1bf6@mail.gmail.com> In-Reply-To: <5bc218350909041002x670460c8nf202a714182d1bf6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: UDP output performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 11:40:17 -0000 Manish Vachharajani wrote: > Hmm, what version of FreeBSD are you using? I don't know the solution > but I wonder if it is related to a similar problem we are having with > TCP connection scaling, both under 7.2 and 8.0 over a 10 Gb link. > We've been trying to track it down, and if you see it for UDP as well > that may give some clues. > > If you do a netstat -idh what is the output? Does the recieving > interface show any Ierrs or drops? If so, you should be able to do a > sysctl dev.em..stats=1 and then see some output via > dmesg. Does this show any missed packets? > > Oh, also, what kind of machine are you running on? Well this turns out to be a pilot error, in that I created such a complex bandwidth evaluation that on buffer full the packet got tossed in the application. :( Just stripping that out, and just do a try send while(not send) { usleep(1 packet-time); try again; } Reduced my packet loss to < 0.1% and I'm able to squeeze a nice > 900 Mbit/s out of a single em(4) port. Still no packets begin dropped in netstat -i. So now I'm off hunting for 'bugs' in snmp, cacti, mrtg to see why they don't like the counters. Even when I'm using the 64bit counters I get really spiky bandwidth results. Equal to those when using 32 bits counters, so certainly things are not as I think they are. Other thing is to see how Lin* is performing on this test. So trying to install ubuntu 9.04. --WjW From owner-freebsd-net@FreeBSD.ORG Mon Sep 7 13:39:08 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48FEB106566B for ; Mon, 7 Sep 2009 13:39:08 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 17B578FC1E for ; Mon, 7 Sep 2009 13:39:08 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n87D1kqY062913; Mon, 7 Sep 2009 09:01:47 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200909071301.n87D1kqY062913@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 07 Sep 2009 09:05:30 -0400 To: Willem Jan Withagen From: Mike Tancsa In-Reply-To: <4AA4F11C.4060200@digiware.nl> References: <4AA14018.3010102@digiware.nl> <5bc218350909041002x670460c8nf202a714182d1bf6@mail.gmail.com> <4AA4F11C.4060200@digiware.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: net@freebsd.org Subject: Re: UDP output performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 13:39:08 -0000 At 07:40 AM 9/7/2009, Willem Jan Withagen wrote: >Well this turns out to be a pilot error, in that I created such a >complex bandwidth evaluation that on buffer full the packet got >tossed in the application. >:( > >Just stripping that out, and just do a > >try send >while(not send) { > usleep(1 packet-time); > try again; >} There are some nice simples tool in /usr/src/tools/tools/netrate that are great for generating arbitrary bandwidth via udp packets you might want to have a look at. ---Mike > >Reduced my packet loss to < 0.1% and I'm able to squeeze a nice > >900 Mbit/s out of a single em(4) port. Still no packets begin >dropped in netstat -i. > >So now I'm off hunting for 'bugs' in snmp, cacti, mrtg to see why >they don't like the counters. Even when I'm using the 64bit counters >I get really spiky bandwidth results. Equal to those when using 32 >bits counters, so certainly things are not as I think they are. > >Other thing is to see how Lin* is performing on this test. >So trying to install ubuntu 9.04. > >--WjW >_______________________________________________ >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" -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-net@FreeBSD.ORG Mon Sep 7 13:49:19 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5DAD106568F for ; Mon, 7 Sep 2009 13:49:19 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (unknown [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 426048FC27 for ; Mon, 7 Sep 2009 13:49:19 +0000 (UTC) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id F125D153434; Mon, 7 Sep 2009 15:49:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnZQigyaLFSD; Mon, 7 Sep 2009 15:49:15 +0200 (CEST) Received: from [212.61.27.67] (opteron [212.61.27.67]) by mail.digiware.nl (Postfix) with ESMTP id E1D08153433; Mon, 7 Sep 2009 15:49:15 +0200 (CEST) Message-ID: <4AA50F5B.1080600@digiware.nl> Date: Mon, 07 Sep 2009 15:49:15 +0200 From: Willem Jan Withagen Organization: Digiware User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Mike Tancsa References: <4AA14018.3010102@digiware.nl> <5bc218350909041002x670460c8nf202a714182d1bf6@mail.gmail.com> <4AA4F11C.4060200@digiware.nl> <200909071301.n87D1kqY062913@lava.sentex.ca> In-Reply-To: <200909071301.n87D1kqY062913@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: UDP output performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 13:49:19 -0000 Mike Tancsa wrote: > At 07:40 AM 9/7/2009, Willem Jan Withagen wrote: > >> Well this turns out to be a pilot error, in that I created such a >> complex bandwidth evaluation that on buffer full the packet got tossed >> in the application. >> :( >> >> Just stripping that out, and just do a >> >> try send >> while(not send) { >> usleep(1 packet-time); >> try again; >> } > > There are some nice simples tool in /usr/src/tools/tools/netrate that > are great for generating arbitrary bandwidth via udp packets you might > want to have a look at. Thanx Mike, I'll have a look. Always better well copied, than badly self invented. (free to an old dutch proverb). :) Reason I'm home growing, is that these tests are for really specific applications we're developing. And the actual purpose is to find hardware combo's that will do UDP packets a fast at we can get it out of the ports. Preferably with a 10Gbit card at close to 10Gb/s. But thus far I'm only getting the intel hardware on 1Gbit close to the line max. But I've got several boards still to test. As I side note: If anybody had experience with 10Gb hardware, I would appreciate recommandations for that as well. One of the piexes of hardware I'm currently evaluating is: Which does a nice job, with 2mbit udp in on em0 and 1Gbit udp out on port em6. --WjW From owner-freebsd-net@FreeBSD.ORG Mon Sep 7 14:35:45 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBE61106566B for ; Mon, 7 Sep 2009 14:35:45 +0000 (UTC) (envelope-from dyr@homelink.ru) Received: from relay.eltel.net (relay.eltel.net [81.9.101.72]) by mx1.freebsd.org (Postfix) with ESMTP id 9148B8FC14 for ; Mon, 7 Sep 2009 14:35:45 +0000 (UTC) Received: from mail.homelink.ru ([81.9.33.123] helo=eltel.net) by relay.eltel.net with esmtp (Exim 4.63) (envelope-from ) id 1MkZ43-0001fS-HW; Mon, 07 Sep 2009 11:55:03 +0400 Received: from [85.249.167.249] (account dyr@homelink.ru HELO localhost) by eltel.net (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 29073082; Mon, 07 Sep 2009 11:55:03 +0400 Date: Mon, 7 Sep 2009 11:54:55 +0400 From: Dennis Yusupoff X-Mailer: The Bat! (v4.0.24) Professional Organization: Severen-Home ISP X-Priority: 3 (Normal) Message-ID: <1116202669.20090907115455@homelink.ru> To: freebsd-isp@freebsd.org, freebsd-net@freebsd.org In-Reply-To: <4AA46103.9000108@elischer.org> References: <4AA46103.9000108@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 3.3 X-Spam-Report: Mail system is relay.eltel.net Contact postmaster@eltel.net for details. Content analysis details: (3.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.8 UNWANTED_LANGUAGE_BODY BODY: Message written in an undesired language 0.5 BAYES_50 BODY: Bayesian spam probability is 40 to 60% [score: 0.5000] X-Spam-Flag: NO X-Mailman-Approved-At: Mon, 07 Sep 2009 14:54:45 +0000 Cc: freebsd-isp@freebsd.org, freebsd-net@freebsd.org, grarpamp Subject: Re[2]: Call for testers: ng_netflow with v9 and IPv6 support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 14:35:45 -0000 By the way, what's about this one: --- The ng_netflow node type does not fill in AS numbers. This is due to = the lack of necessary information in the kernel routing table. However, t= his information can be injected into the kernel from a routing daemon such= as GNU Zebra. This functionality may become available in future releases. --- Is any chance to see it in, for example, 8.0? --=20 =D1 =F3=E2=E0=E6=E5=ED=E8=E5=EC, =F1=E8=F1=F2=E5=EC=ED=FB=E9 =E0=E4=EC=E8=ED=E8=F1=F2=F0=E0=F2=EE=F0=20 Ozerki.Net/Cifracom.Ru =DE=F1=F3=EF=EE=E2 =C4=E5=ED=E8=F1 mailto:dyr@ho= melink.ru From owner-freebsd-net@FreeBSD.ORG Mon Sep 7 16:33:57 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D4541065742 for ; Mon, 7 Sep 2009 16:33:57 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6F90E8FC13 for ; Mon, 7 Sep 2009 16:33:57 +0000 (UTC) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id n87GKo4f064428; Mon, 7 Sep 2009 09:20:50 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from [172.16.1.4] (cpe-68-175-77-169.nyc.res.rr.com [68.175.77.169]) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.3) with ESMTP id n87GKncV078120 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Sep 2009 09:20:50 -0700 (PDT) (envelope-from gnn@neville-neil.com) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: George Neville-Neil In-Reply-To: <20090904223123.GD16213@hal.rescomp.berkeley.edu> Date: Mon, 7 Sep 2009 12:20:48 -0400 Content-Transfer-Encoding: 7bit Message-Id: <723505E9-96C6-401C-A844-3D9BA2033795@neville-neil.com> References: <20090904223123.GD16213@hal.rescomp.berkeley.edu> To: Chris Cowart X-Mailer: Apple Mail (2.1075.2) Cc: freebsd-net@freebsd.org Subject: Re: Crash in ether_input X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 16:33:57 -0000 On Sep 4, 2009, at 18:31 , Chris Cowart wrote: > Hello, > > Starting about a week ago, our primary webserver (then running FreeBSD > 7.0) began crashing several times a day, typically during our > higher-load times of day. We have since upgraded to 7.1p7, but > continued > to see the frequent crashes. > > We are running an apache22 webserver with a lot of perl, logging via > syslog-ng, and using IPSec in transport mode between the webserver and > both the fileserver and logserver. Everything is IPv4. > > From uname: > > | FreeBSD mug.rescomp.berkeley.edu 7.1-RELEASE-p7 FreeBSD 7.1- > RELEASE-p7 > | #0: Wed Sep 2 17:56:59 PDT 2009 > | root@mug.rescomp.berkeley.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > Some information that appears typical across many crashes: > > | Unread portion of the kernel message buffer: > | > | Fatal trap 27: stack fault while in kernel mode > | cpuid = 0; apic id = 00 > | instruction pointer = 0x8:0xffffffff80559fb4 > | stack pointer = 0x10:0xffffffffae39faf0 > | frame pointer = 0x10:0xf85ecc37f9239402 > | code segment = base 0x0, limit 0xfffff, type 0x1b > | = DPL 0, pres 1, long 1, def32 0, gran 1 > | processor eflags = interrupt enabled, resume, IOPL = 0 > | current process = 27 (em0 taskq) > | trap number = 27 > | panic: stack fault > | cpuid = 0 > | Uptime: 43m44s > | Physical memory: 4082 MB > | Dumping 361 MB: 346 330 314 298 282 266 250 234 218 202em0: > watchdog timeout -- resetting > > | (kgdb) bt > | #0 doadump () at pcpu.h:195 > | #1 0x0000000000000004 in ?? () > | #2 0xffffffff804bd9b9 in boot (howto=260) at /usr/src/sys/kern/ > kern_shutdown.c:418 > | #3 0xffffffff804bddc2 in panic (fmt=0x104
bounds>) at /usr/src/sys/kern/kern_shutdown.c:574 > | #4 0xffffffff807b9f23 in trap_fatal (frame=0xffffff00012d66e0, > eva=Variable "eva" is not available. > | ) at /usr/src/sys/amd64/amd64/trap.c:764 > | #5 0xffffffff807baa75 in trap (frame=0xffffffffae39fa40) at /usr/ > src/sys/amd64/amd64/trap.c:565 > | #6 0xffffffff807a042e in calltrap () at /usr/src/sys/amd64/amd64/ > exception.S:209 > | #7 0xffffffff80559fb4 in ether_input (ifp=0xffffff00012bf000, > m=0xffffff0003576000) at /usr/src/sys/net/if_ethersubr.c:545 > | #8 0xffffffff802bd645 in em_rxeof (adapter=0xffffffff80e4c000, > count=99) at /usr/src/sys/dev/e1000/if_em.c:4539 > | #9 0xffffffff802be55e in em_handle_rxtx (context=Variable > "context" is not available. > | ) at /usr/src/sys/dev/e1000/if_em.c:1702 > | #10 0xffffffff804f2afd in taskqueue_run (queue=0xffffff00012c8c80) > at /usr/src/sys/kern/subr_taskqueue.c:282 > | #11 0xffffffff804f2da6 in taskqueue_thread_loop (arg=Variable > "arg" is not available. > | ) at /usr/src/sys/kern/subr_taskqueue.c:401 > | #12 0xffffffff8049b2f3 in fork_exit (callout=0xffffffff804f2d40 > , arg=0xffffffff80e50588, > frame=0xffffffffae39fc80) at /usr/src/sys/kern/kern_fork.c:804 > | #13 0xffffffff807a07fe in fork_trampoline () at /usr/src/sys/amd64/ > amd64/exception.S:455 > | #14 0x0000000000000000 in ?? () > | #15 0x0000000000000000 in ?? () > | #16 0x0000000000000001 in ?? () > [...] > > | (kgdb) source debug/gdb6 > | (kgdb) frame 7 > | #7 0xffffffff80559fb4 in ether_input (ifp=0xffffff00012bf000, > m=0xffffff0003576000) at /usr/src/sys/net/if_ethersubr.c:545 > | 545 eh = mtod(m, struct ether_header *); > | (kgdb) info locals > | eh = (struct ether_header *) 0xf85ecc37f9239402 > | (kgdb) info args > | ifp = (struct ifnet *) 0xffffff00012bf000 > | m = (struct mbuf *) 0xffffff0003576000 > | (kgdb) mbuf m > | 0xffffff0003576000: 125 bytes ext 0xaf29dcb45d53e701 packet: 125 > bytes received via em0 > | 0xbb763383e10eda22Cannot access memory at address 0xbb763383e10eda3a > | (kgdb) > > If anyone can provide some points on other things I can try to get > useful data out of these core dumps, I'm open to it. > > We did decide to stop mounting NFS, upgrade to syslog-ng3 (which > supports TLS), and revert the webserver back to a GENERIC kernel. > Since > booting the GENERIC kernel, the system has been up for nearly 2 days. > > Right now, we're logging via TLS to a temporary/testing logserver. > That > logserver is one of our default builds with IPSec. It is configured to > forward logs over udp/syslog (via IPSec in transport mode) to our > primary logserver. > > Within hours of beginning to pass the production webserver's logs > through this temporary logserver (and thus having its syslog-ng > forward > to the primary logserver), the temporary logserver began exhibiting > the > same behavior that the webserver was previously showing. > > We're totally grasping at straws here, but it's looking like some kind > of bug related to IPSec. Maybe related to long messages? High volume > of > messages? > > We would love to get this hammered out, so please let me know if > there's > any debugging we can perform or patches we can try. > Hi Chris, Sorry to hear y'all are having problems. You mention that you switched to GENERIC? Can you send out a copy of your modified kernel config? I'm a bit confused because the kernel panic you do show looks like it's from a GENERIC kernel. Are you setting any of the em device's kernel tunables? How is your IPSEC stuff built in to the kernel and are you setting any kernel variables for it? My best guess from the stack trace is a buffer that is not being returned properly somewhere between the device and the IPsec subsystem. Best, George From owner-freebsd-net@FreeBSD.ORG Mon Sep 7 19:10:06 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7639106568B for ; Mon, 7 Sep 2009 19:10:06 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: from hal.rescomp.berkeley.edu (hal.Rescomp.Berkeley.EDU [169.229.70.150]) by mx1.freebsd.org (Postfix) with ESMTP id BD20F8FC2E for ; Mon, 7 Sep 2009 19:10:06 +0000 (UTC) Received: by hal.rescomp.berkeley.edu (Postfix, from userid 1225) id 0D3FA597C49; Mon, 7 Sep 2009 12:10:01 -0700 (PDT) Date: Mon, 7 Sep 2009 12:10:01 -0700 From: Chris Cowart To: George Neville-Neil Message-ID: <20090907191001.GA37291@hal.rescomp.berkeley.edu> Mail-Followup-To: George Neville-Neil , freebsd-net@freebsd.org References: <20090904223123.GD16213@hal.rescomp.berkeley.edu> <723505E9-96C6-401C-A844-3D9BA2033795@neville-neil.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: <723505E9-96C6-401C-A844-3D9BA2033795@neville-neil.com> Organization: RSSP-IT, UC Berkeley User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net@freebsd.org Subject: Re: Crash in ether_input X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 19:10:07 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable George Neville-Neil wrote: > On Sep 4, 2009, at 18:31 , Chris Cowart wrote: > > Starting about a week ago, our primary webserver (then running FreeBSD > > 7.0) began crashing several times a day, typically during our > > higher-load times of day. We have since upgraded to 7.1p7, but =20 > > continued > > to see the frequent crashes. > > > > We are running an apache22 webserver with a lot of perl, logging via > > syslog-ng, and using IPSec in transport mode between the webserver and > > both the fileserver and logserver. Everything is IPv4. > > > > From uname: > > > > | FreeBSD mug.rescomp.berkeley.edu 7.1-RELEASE-p7 FreeBSD 7.1-=20 > > RELEASE-p7 > > | #0: Wed Sep 2 17:56:59 PDT 2009 > > | root@mug.rescomp.berkeley.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > > > Some information that appears typical across many crashes: > > > > | Unread portion of the kernel message buffer: > > | > > | Fatal trap 27: stack fault while in kernel mode > > | cpuid =3D 0; apic id =3D 00 > > | instruction pointer =3D 0x8:0xffffffff80559fb4 > > | stack pointer =3D 0x10:0xffffffffae39faf0 > > | frame pointer =3D 0x10:0xf85ecc37f9239402 > > | code segment =3D base 0x0, limit 0xfffff, type 0x1b > > | =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > | processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > > | current process =3D 27 (em0 taskq) > > | trap number =3D 27 > > | panic: stack fault > > | cpuid =3D 0 > > | Uptime: 43m44s > > | Physical memory: 4082 MB > > | Dumping 361 MB: 346 330 314 298 282 266 250 234 218 202em0: =20 > > watchdog timeout -- resetting > > > > | (kgdb) bt > > | #0 doadump () at pcpu.h:195 > > | #1 0x0000000000000004 in ?? () > > | #2 0xffffffff804bd9b9 in boot (howto=3D260) at /usr/src/sys/kern/=20 > > kern_shutdown.c:418 > > | #3 0xffffffff804bddc2 in panic (fmt=3D0x104
> bounds>) at /usr/src/sys/kern/kern_shutdown.c:574 > > | #4 0xffffffff807b9f23 in trap_fatal (frame=3D0xffffff00012d66e0, =20 > > eva=3DVariable "eva" is not available. > > | ) at /usr/src/sys/amd64/amd64/trap.c:764 > > | #5 0xffffffff807baa75 in trap (frame=3D0xffffffffae39fa40) at /usr/= =20 > > src/sys/amd64/amd64/trap.c:565 > > | #6 0xffffffff807a042e in calltrap () at /usr/src/sys/amd64/amd64/=20 > > exception.S:209 > > | #7 0xffffffff80559fb4 in ether_input (ifp=3D0xffffff00012bf000, =20 > > m=3D0xffffff0003576000) at /usr/src/sys/net/if_ethersubr.c:545 > > | #8 0xffffffff802bd645 in em_rxeof (adapter=3D0xffffffff80e4c000, =20 > > count=3D99) at /usr/src/sys/dev/e1000/if_em.c:4539 > > | #9 0xffffffff802be55e in em_handle_rxtx (context=3DVariable =20 > > "context" is not available. > > | ) at /usr/src/sys/dev/e1000/if_em.c:1702 > > | #10 0xffffffff804f2afd in taskqueue_run (queue=3D0xffffff00012c8c80) = =20 > > at /usr/src/sys/kern/subr_taskqueue.c:282 > > | #11 0xffffffff804f2da6 in taskqueue_thread_loop (arg=3DVariable =20 > > "arg" is not available. > > | ) at /usr/src/sys/kern/subr_taskqueue.c:401 > > | #12 0xffffffff8049b2f3 in fork_exit (callout=3D0xffffffff804f2d40 =20 > > , arg=3D0xffffffff80e50588, =20 > > frame=3D0xffffffffae39fc80) at /usr/src/sys/kern/kern_fork.c:804 > > | #13 0xffffffff807a07fe in fork_trampoline () at /usr/src/sys/amd64/= =20 > > amd64/exception.S:455 > > | #14 0x0000000000000000 in ?? () > > | #15 0x0000000000000000 in ?? () > > | #16 0x0000000000000001 in ?? () > > [...] > > > > | (kgdb) source debug/gdb6 > > | (kgdb) frame 7 > > | #7 0xffffffff80559fb4 in ether_input (ifp=3D0xffffff00012bf000, =20 > > m=3D0xffffff0003576000) at /usr/src/sys/net/if_ethersubr.c:545 > > | 545 eh =3D mtod(m, struct ether_header *); > > | (kgdb) info locals > > | eh =3D (struct ether_header *) 0xf85ecc37f9239402 > > | (kgdb) info args > > | ifp =3D (struct ifnet *) 0xffffff00012bf000 > > | m =3D (struct mbuf *) 0xffffff0003576000 > > | (kgdb) mbuf m > > | 0xffffff0003576000: 125 bytes ext 0xaf29dcb45d53e701 packet: 125 =20 > > bytes received via em0 > > | 0xbb763383e10eda22Cannot access memory at address 0xbb763383e10eda3a > > | (kgdb) > > > > If anyone can provide some points on other things I can try to get > > useful data out of these core dumps, I'm open to it. > > > > We did decide to stop mounting NFS, upgrade to syslog-ng3 (which > > supports TLS), and revert the webserver back to a GENERIC kernel. =20 > > Since > > booting the GENERIC kernel, the system has been up for nearly 2 days. > > > > Right now, we're logging via TLS to a temporary/testing logserver. =20 > > That > > logserver is one of our default builds with IPSec. It is configured to > > forward logs over udp/syslog (via IPSec in transport mode) to our > > primary logserver. > > > > Within hours of beginning to pass the production webserver's logs > > through this temporary logserver (and thus having its syslog-ng =20 > > forward > > to the primary logserver), the temporary logserver began exhibiting =20 > > the > > same behavior that the webserver was previously showing. > > > > We're totally grasping at straws here, but it's looking like some kind > > of bug related to IPSec. Maybe related to long messages? High volume = =20 > > of > > messages? > > > > We would love to get this hammered out, so please let me know if =20 > > there's > > any debugging we can perform or patches we can try. > > >=20 > Hi Chris, >=20 > Sorry to hear y'all are having problems. You mention that you > switched to GENERIC? Can you send out a copy of your modified kernel > config? I'm a bit confused because the kernel panic you do show > looks like it's from a GENERIC kernel. Sorry, the uname was from a stable boot after we had switched to GENERIC.=20 The config from the crashing kernel: | include GENERIC |=20 | ident RCBSD_REL7 |=20 | # Enabling IPSec (see SysAdmin.IPSec in TWiki) | options IPSEC =20 | options IPSEC_FILTERTUNNEL | device crypto |=20 | # Enabling quota support | options QUOTA > Are you setting any of the em device's kernel tunables? Nope. Some more details on the hardware: | [ccowart@mug /usr/local/rescomp/etc/online-helpdesk]$ dmesg | grep em0 | em0: port 0xece0-0xecff mem = 0xfc3e0000-0xfc3fffff,0xfc3c0000-0xfc3dffff irq 16 at device 0.0 on pci14 | em0: Using MSI interrupt | em0: [FILTER] | em0: Ethernet address: 00:15:17:7a:b5:e0 | em0: link state changed to UP > How is your IPSEC stuff built in to the kernel and are you setting any > kernel variables for it? See the kernel config above. We are not tuning via sysctls or the loader.conf. All of that should be stock for IPSEC. The host is configured with 2 peers for IPSec communication. We use racoon and x509 certificates. > My best guess from the stack trace is a buffer that is not being > returned properly somewhere between the device and the IPsec > subsystem. One of my coworkers has been able to reproduce the crash by syslogging really long lines. I'm planning to spend some time today to try to create a smaller example case on a couple of vms. --=20 Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iQIcBAEBAwAGBQJKpVqIAAoJEC8b9sM8ejXtPVwP/0aL4JV7k1QSwAdrb3qz9kSo yqZk1jLAjG8ripUtcmwB/8VUXhhWVsb50FO+4ww312CGEweh4qA5ii5yMGIbBYa9 7PCo8FEIoHpRicWsxcJQ5sKJuNmjWdeJEYu89tivuvxlqjer7eMuOGIrDwTE+7kQ cYfaaLFLxkCBXj/9Fd5tEduetZcknmIQKNbPdKXeiCN3SPwctDE/OcYOUw30aBXx N+YZCJD1knKdFo+ck9RLb2bMTAn5Z+C+nwGRjMIwp++xK/QYI54YYZgZs7n+W45B hL6soVBHCAcBUfLPjrykF1kEsiWMfo/nFbIkD8/TAtpMdAev+V/LQSHpUmmPBxdZ PO9xqh9C82lYjlu7/6yDix5jRvu9QT41JEuPTodWDtGaGzTu2NGBqdXgdgEYjPGd 0ozciCbONPf2ZM7RNTlMl8u/NEOj7pKHirQmL8+gsrt9Vg39LaCbHlc7/mQNTISV u/Pz2ZHBUUz0NU9l91IQii1YN7WzOWzuuwTiXYACIYyhUudvrEYS3jTD0sZjm8Ap etqstxFfAYxXdga1PvsC7hx0/jxsVFEQJgfZt+RPKChHGi4lrh0LIANFkACNo0LV LX7TkPtUDQu7KgmMIukowSFEb2JxWZecc9zIUyjFn732iJ0K5sc0/KT6BYLMs08p dpOI+RnG5pxtYv9dRL1N =J/0b -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF-- From owner-freebsd-net@FreeBSD.ORG Mon Sep 7 21:03:34 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A6C91065693; Mon, 7 Sep 2009 21:03:34 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx10.syd.optusnet.com.au (fallbackmx10.syd.optusnet.com.au [211.29.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id A146E8FC0A; Mon, 7 Sep 2009 21:03:33 +0000 (UTC) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by fallbackmx10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n87JufNe023084; Tue, 8 Sep 2009 05:56:41 +1000 Received: from server.vk2pj.dyndns.org (c122-106-217-45.belrs3.nsw.optusnet.com.au [122.106.217.45]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n87Jubsq004145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Sep 2009 05:56:38 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n87JuagG041181; Tue, 8 Sep 2009 05:56:37 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n87Jua3g041180; Tue, 8 Sep 2009 05:56:36 +1000 (EST) (envelope-from peter) Date: Tue, 8 Sep 2009 05:56:36 +1000 From: Peter Jeremy To: Dennis Yusupoff Message-ID: <20090907195636.GB35275@server.vk2pj.dyndns.org> References: <4AA46103.9000108@elischer.org> <1116202669.20090907115455@homelink.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TRYliJ5NKNqkz5bu" Content-Disposition: inline In-Reply-To: <1116202669.20090907115455@homelink.ru> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-isp@freebsd.org, freebsd-net@freebsd.org Subject: Re: Re[2]: Call for testers: ng_netflow with v9 and IPv6 support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 21:03:34 -0000 --TRYliJ5NKNqkz5bu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Sep-07 11:54:55 +0400, Dennis Yusupoff wrote: >By the way, what's about this one: >--- > The ng_netflow node type does not fill in AS numbers. This is due to= the =2E.. >--- > >Is any chance to see it in, for example, 8.0? New feature cutoff for 8.0 was several months ago. Once the code exists, it may be a candidate for inclusion in a future 8.x release. --=20 Peter Jeremy --TRYliJ5NKNqkz5bu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkqlZXQACgkQ/opHv/APuIdndwCgmdtSQk8X9j31YuseFEIL1q22 +F4AnjifLddBcdFKs4BbSMxr5O1D3cVi =xh8+ -----END PGP SIGNATURE----- --TRYliJ5NKNqkz5bu-- From owner-freebsd-net@FreeBSD.ORG Tue Sep 8 00:08:37 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB1F6106566B for ; Tue, 8 Sep 2009 00:08:37 +0000 (UTC) (envelope-from stef-list@memberwebs.com) Received: from mail.npubs.com (mail.npubs.com [74.82.45.72]) by mx1.freebsd.org (Postfix) with ESMTP id 9F0078FC0C for ; Tue, 8 Sep 2009 00:08:37 +0000 (UTC) Resent-Message-Id: From: Stef Walter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: stef@memberwebs.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Resent-Date: Tue, 8 Sep 2009 00:08:37 +0000 (UTC) Resent-From: stef-list@memberwebs.com Cc: "freebsd-net@FreeBSD.org" , bms@incunabulum.net Subject: Re: Panic in imo_match_source (netinet/in_mcast.c) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stef@memberwebs.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 08 Sep 2009 00:08:37 -0000 X-List-Received-Date: Tue, 08 Sep 2009 00:08:37 -0000 Stef Walter wrote: > On a new VPN server, running OSPF, I'm experiencing regular panics at: > > imo_match_source: !AF_INET BTW, src->sa_family is 0 Moved back to FreeBSD 7.1 i386 and the problem goes away. Cheers, Stef From owner-freebsd-net@FreeBSD.ORG Tue Sep 8 07:50:34 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48D06106568B for ; Tue, 8 Sep 2009 07:50:34 +0000 (UTC) (envelope-from john@traktor.dnepro.net) Received: from traktor.dnepro.net (roof1.dnepro.net [212.3.111.66]) by mx1.freebsd.org (Postfix) with ESMTP id 6A0508FC18 for ; Tue, 8 Sep 2009 07:50:32 +0000 (UTC) Received: from traktor.dnepro.net (localhost [127.0.0.1]) by traktor.dnepro.net (8.14.3/8.14.3) with ESMTP id n887oUkE010275; Tue, 8 Sep 2009 10:50:30 +0300 (EEST) (envelope-from john@traktor.dnepro.net) Received: (from john@localhost) by traktor.dnepro.net (8.14.3/8.14.3/Submit) id n887oUPF010274; Tue, 8 Sep 2009 10:50:30 +0300 (EEST) (envelope-from john) Date: Tue, 8 Sep 2009 10:50:30 +0300 From: Eugene Perevyazko To: freebsd-net@freebsd.org Message-ID: <20090908075030.GA6644@traktor.dnepro.net> Mail-Followup-To: freebsd-net@freebsd.org, Pyun YongHyeon References: <20090821142039.GA40018@traktor.dnepro.net> <20090821221932.GE1262@michelle.cdnetworks.com> <20090825083857.GA22983@traktor.dnepro.net> <20090825114649.GA11642@traktor.dnepro.net> <20090825130821.GA41669@traktor.dnepro.net> <20090825182553.GD1282@michelle.cdnetworks.com> <20090826093916.GB10790@traktor.dnepro.net> <20090826094856.GC10790@traktor.dnepro.net> <20090901161310.GA37481@traktor.dnepro.net> <20090904212223.GA9950@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090904212223.GA9950@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: Pyun YongHyeon Subject: Re: D-Link DGE-560SX (Marvell 88E8061-based) doesn't see link X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 07:50:34 -0000 On Fri, Sep 04, 2009 at 02:22:23PM -0700, Pyun YongHyeon wrote: > > Would you back out previous changes and apply the patch at the > following URL? > http://people.freebsd.org/~yongari/msk/msk.DGE560.diff2 > > Note, I have no more access to msk(4) hardwares so it wasn't tested > at all except compilation. > Still no success. mskc0: port 0xd800-0xd8ff mem 0xfeafc000-0xfeafffff irq 16 at device 0.0 on pci1 msk0: on mskc0 msk0: Ethernet address: 00:21:91:52:4f:09 miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 1000baseSX, 1000baseSX-FDX, auto mskc0: [FILTER] ifconfig -m msk0 msk0: flags=8843 metric 0 mtu 1500 options=11a capabilities=11a ether 00:21:91:52:4f:09 inet 10.2.3.1 netmask 0xffffff00 broadcast 10.2.3.255 media: Ethernet autoselect (autoselect ) status: active supported media: media autoselect media 1000baseSX mediaopt full-duplex media 1000baseSX media none Switch shows no link on the port. # ifconfig msk0 media 1000baseSX mediaopt full-duplex # ifconfig msk0 msk0: flags=8843 metric 0 mtu 1500 options=11a ether 00:21:91:52:4f:09 inet 10.2.3.1 netmask 0xffffff00 broadcast 10.2.3.255 media: Ethernet 1000baseSX (autoselect ) status: active Switch shows no link again. All dev.msk.0.stats counters are zero even after trying broadcast ping. I can arrange you root access to the host with this NIC if you have time/wish. -- Eugene Perevyazko From owner-freebsd-net@FreeBSD.ORG Tue Sep 8 13:04:41 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A48391065672 for ; Tue, 8 Sep 2009 13:04:41 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 77F838FC1C for ; Tue, 8 Sep 2009 13:04:41 +0000 (UTC) Received: from compute2.internal (compute2.internal [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id 3A1EE64D17; Tue, 8 Sep 2009 09:04:40 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 08 Sep 2009 09:04:40 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:cc:subject:content-type:content-transfer-encoding; s=smtpout; bh=VVR//plplxi9i53+kkqaTJVdUgI=; b=Dgh8METnp8iL6fSTd53N37AlwB8A9JAtw47jgpwb9SN28deOtD/ciVMicIVorSo+Fvtxeisr7m02Py+/G2pv6iSx0XnP5xytEpUsXE9o35ZP4E6NAicWAJGo8Mz8v7/s/gUmoTSjpCxLh1oAv1W6wZ7o9j4ixHgEQrFlNMEcMFU= X-Sasl-enc: Jh1k9DpBRxdma3cdlRFfO78oUn2UXJYVgeP2miiAHcX0 1252415079 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id AAC9668092; Tue, 8 Sep 2009 09:04:39 -0400 (EDT) Message-ID: <4AA65663.8050106@incunabulum.net> Date: Tue, 08 Sep 2009 14:04:35 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: stef@memberwebs.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@FreeBSD.org" Subject: Re: Panic in imo_match_source (netinet/in_mcast.c) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 13:04:41 -0000 Stef Walter wrote: > Stef Walter wrote: > >> On a new VPN server, running OSPF, I'm experiencing regular panics at: >> >> imo_match_source: !AF_INET >> > > BTW, src->sa_family is 0 > > Moved back to FreeBSD 7.1 i386 and the problem goes away. > Full OS version, dmesg, panic and backtrace please, when reporting this kind of issue... otherwise folk can't help. Are you using SSM multicast features? From owner-freebsd-net@FreeBSD.ORG Tue Sep 8 13:13:12 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31224106566C for ; Tue, 8 Sep 2009 13:13:12 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 02B308FC08 for ; Tue, 8 Sep 2009 13:13:11 +0000 (UTC) Received: from compute2.internal (compute2.internal [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id 3446968E5E; Tue, 8 Sep 2009 09:13:10 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 08 Sep 2009 09:13:10 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=poFZRoXmtyh0QZ3nhD1ZtWRN5pE=; b=KS1hAdy6MbvoYNB50kFiXvFhIQZcipY2Vi490/3amq8KoXSxZ1Mk/VjHEVBjvpL2/k+UcAxWBmxSEAVFZWheLk9RifAXXH5pFnNw0x3ERTQBH3fKggFLoihXRRXbpTw06wY76vkaX0N+MReXl81B0t/kq2EwjW/14mPjdi7UKq0= X-Sasl-enc: 5s75L+GwyIJMr4h3A0w/VDbIwc1VdkFLTXZ/vN2mwuY9 1252415589 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id B19016812D; Tue, 8 Sep 2009 09:13:09 -0400 (EDT) Message-ID: <4AA65861.8@incunabulum.net> Date: Tue, 08 Sep 2009 14:13:05 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: stef@memberwebs.com References: <4AA65663.8050106@incunabulum.net> In-Reply-To: <4AA65663.8050106@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@FreeBSD.org" Subject: Re: Panic in imo_match_source (netinet/in_mcast.c) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 13:13:12 -0000 [Brief reply as I'm meant to be doing a zillion other things...] Bruce Simpson wrote: > > Full OS version, dmesg, panic and backtrace please, when reporting > this kind of issue... otherwise folk can't help. Are you using SSM > multicast features? P.S. You might want to try demoting the KASSERT to a conditional error return (return no match if src is NULL or src->sa_family != AF_INET), and see if that fix 'just works' for you. Sometimes the asserts I sprinkle into code are too paranoid for what's going on, and syrinx@ recently caught one of those. I can see some situations where this could kick off, so that is probably the right fix. Please do let me know. If that fix works for you then it can probably be checked in. There is an RC cutoff looming, so if I can't do it in time, someone else may be able to check it in. thanks, BMS From owner-freebsd-net@FreeBSD.ORG Tue Sep 8 14:21:42 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 935DF1065672 for ; Tue, 8 Sep 2009 14:21:42 +0000 (UTC) (envelope-from shteryana@gmail.com) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by mx1.freebsd.org (Postfix) with ESMTP id 2AFA78FC13 for ; Tue, 8 Sep 2009 14:21:41 +0000 (UTC) Received: by ewy4 with SMTP id 4so1702047ewy.36 for ; Tue, 08 Sep 2009 07:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=8Pr1UTRt6zxKvahBiaI/34tVs6DcNmxBsygssJausS4=; b=xYH62Jgq1A7Li4G8qdKARSt0WVx5Km9P/+caqUvvXW6su0/j69QAdlvfPc/x8QCp8Q IaP0iWJ+s6ZW6Jlu2C921MUGuQhlQDI3IMs3un/mItsQQSruYNsYM1SKPumFHE8fTUDE hcMSdw6t9JSiOdEpFqD0oQvkwCD0Ai+GWg3jw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HVhCPPw4IgVBwjQiL6xuOXgSTDLT3nezKRSmE5TsZbvsfFHZuU8c5xtGtfSBbie+Ia QsB7Wfu6umuHW51doMjuT2YEcbUdl3CljPSXjiNElQdF4iXOY8tGb5HsYkKA65D9VpiB CqTxF4GNmVBVjBTtaW49pl6iI58ylPzO3rp9s= MIME-Version: 1.0 Received: by 10.211.173.14 with SMTP id a14mr3149610ebp.39.1252418092235; Tue, 08 Sep 2009 06:54:52 -0700 (PDT) In-Reply-To: <4AA65861.8@incunabulum.net> References: <4AA65663.8050106@incunabulum.net> <4AA65861.8@incunabulum.net> Date: Tue, 8 Sep 2009 16:54:52 +0300 Message-ID: <61b573980909080654x50670168x39001267ad81c6a3@mail.gmail.com> From: Shteryana Shopova To: Bruce Simpson Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@FreeBSD.org" , stef@memberwebs.com Subject: Re: Panic in imo_match_source (netinet/in_mcast.c) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 14:21:42 -0000 Hi, I actually managed to get the same kernel dump using the following sample code - http://people.freebsd.org/~syrinx/mcast/mcast_crash.c and the crash is 100% reproducable. A temporary fix is here - http://people.freebsd.org/~syrinx/mcast/in_mcast.c-20090908-01.diff but I actually prefer that we go over the logic in inp_join_group() again before proposing a patch for head as this is the second assert panic I am seeing it causes in the last few days. I can try making up a proper fix if Bruce is busy, but it will take a day or two until I'm able to fully test it. cheers, Shteryana On Tue, Sep 8, 2009 at 4:13 PM, Bruce Simpson wrote: > [Brief reply as I'm meant to be doing a zillion other things...] > > Bruce Simpson wrote: >> >> Full OS version, dmesg, panic and backtrace please, when reporting this >> kind of issue... otherwise folk can't help. Are you using SSM multicast >> features? > > P.S. You might want to try demoting the KASSERT to a conditional error > return (return no match if src is NULL or src->sa_family != AF_INET), and > see if that fix 'just works' for you. Sometimes the asserts I sprinkle into > code are too paranoid for what's going on, and syrinx@ recently caught one > of those. > > I can see some situations where this could kick off, so that is probably the > right fix. Please do let me know. If that fix works for you then it can > probably be checked in. There is an RC cutoff looming, so if I can't do it > in time, someone else may be able to check it in. > > thanks, > BMS > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Sep 8 15:11:30 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06EC0106566B for ; Tue, 8 Sep 2009 15:11:30 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id C987D8FC0C for ; Tue, 8 Sep 2009 15:11:29 +0000 (UTC) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 20F8069019; Tue, 8 Sep 2009 11:11:28 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 08 Sep 2009 11:11:29 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=2f4QJCq9r1NgKRuXGwFrEIbFqSQ=; b=Mr3MaB5o9yuIw6oqgjbvcopzPiaog3y1KTZnIL1tDjrfIizsyKi6C6atQYBvbEjO/F3iDFv78Yhxh6TOWHgNsaE6wlkYOtvUl8Ou4tphwkAOL5ZOCxsmjLiMPppfPc2Ui84ZUVovOFdlyIP9YUsZoqL+7ZAhfoG5RHpZjOxd4Ic= X-Sasl-enc: 3tYi5CCTlf9YMs/vmXQmndCcYQaQcmi3Pu4n7GuMsuaF 1252422688 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 2F146682E6; Tue, 8 Sep 2009 11:11:28 -0400 (EDT) Message-ID: <4AA6741B.9020403@incunabulum.net> Date: Tue, 08 Sep 2009 16:11:23 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Shteryana Shopova References: <4AA65663.8050106@incunabulum.net> <4AA65861.8@incunabulum.net> <61b573980909080654x50670168x39001267ad81c6a3@mail.gmail.com> In-Reply-To: <61b573980909080654x50670168x39001267ad81c6a3@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@FreeBSD.org" , stef@memberwebs.com Subject: Re: Panic in imo_match_source (netinet/in_mcast.c) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 15:11:30 -0000 Shteryana Shopova wrote: > Hi, > > I actually managed to get the same kernel dump using the following > sample code - http://people.freebsd.org/~syrinx/mcast/mcast_crash.c > and the crash is 100% reproducable. A temporary fix is here - > http://people.freebsd.org/~syrinx/mcast/in_mcast.c-20090908-01.diff > but I actually prefer that we go over the logic in inp_join_group() > again before proposing a patch for head as this is the second assert > panic I am seeing it causes in the last few days. I can try making up > a proper fix if Bruce is busy, but it will take a day or two until I'm > able to fully test it. > Good catch. Yes, IP_ADD_MEMBERSHIP on an existing exclusive mode group with filters is an error. The comment calls it out, but you are right, a normal case could hit the KASSERT. The code in the start of inp_join_group() handles all join requests, by mapping 3 possible sets of inbound ioctls onto 1, to make the ioctl processing code smaller. So I could rephrase the fix to: explicitly check for ssa->ss.ss_family being AF_UNSPEC before trying to perform a search with ssa as the key, as this will be set by the code above. Or commit your fix, which is a bit more explicit. The assertion in imo_match_source() existed to catch v4/v6 operations being mixed in similar code paths. Originally I'd planned to keep v4 and v6 code together, but as time went on, it became clear that just branching the code for v6 was the right way to keep the code managable. v6 and v4 have a bunch of special conditions for address handling which just plain need to stay separate... From owner-freebsd-net@FreeBSD.ORG Tue Sep 8 15:50:13 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBD341065676 for ; Tue, 8 Sep 2009 15:50:12 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by mx1.freebsd.org (Postfix) with ESMTP id D05798FC16 for ; Tue, 8 Sep 2009 15:50:12 +0000 (UTC) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id n88FjNvO001398; Tue, 8 Sep 2009 08:45:23 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from gnnmac.hudson-trading.com (209.249.190.8.available.above.net [209.249.190.8] (may be forged)) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.3) with ESMTP id n88FjMxY030721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 Sep 2009 08:45:23 -0700 (PDT) (envelope-from gnn@neville-neil.com) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: George Neville-Neil In-Reply-To: <20090907191001.GA37291@hal.rescomp.berkeley.edu> Date: Tue, 8 Sep 2009 11:45:22 -0400 Content-Transfer-Encoding: 7bit Message-Id: <54FDC10A-EAE3-4AE2-BF36-2C5F7D141C3A@neville-neil.com> References: <20090904223123.GD16213@hal.rescomp.berkeley.edu> <723505E9-96C6-401C-A844-3D9BA2033795@neville-neil.com> <20090907191001.GA37291@hal.rescomp.berkeley.edu> To: Chris Cowart X-Mailer: Apple Mail (2.1075.2) Cc: freebsd-net@freebsd.org Subject: Re: Crash in ether_input X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 15:50:13 -0000 On Sep 7, 2009, at 15:10 , Chris Cowart wrote: > George Neville-Neil wrote: >> On Sep 4, 2009, at 18:31 , Chris Cowart wrote: >>> Starting about a week ago, our primary webserver (then running >>> FreeBSD >>> 7.0) began crashing several times a day, typically during our >>> higher-load times of day. We have since upgraded to 7.1p7, but >>> continued >>> to see the frequent crashes. >>> >>> We are running an apache22 webserver with a lot of perl, logging via >>> syslog-ng, and using IPSec in transport mode between the webserver >>> and >>> both the fileserver and logserver. Everything is IPv4. >>> >>> From uname: >>> >>> | FreeBSD mug.rescomp.berkeley.edu 7.1-RELEASE-p7 FreeBSD 7.1- >>> RELEASE-p7 >>> | #0: Wed Sep 2 17:56:59 PDT 2009 >>> | root@mug.rescomp.berkeley.edu:/usr/obj/usr/src/sys/GENERIC amd64 >>> >>> Some information that appears typical across many crashes: >>> >>> | Unread portion of the kernel message buffer: >>> | >>> | Fatal trap 27: stack fault while in kernel mode >>> | cpuid = 0; apic id = 00 >>> | instruction pointer = 0x8:0xffffffff80559fb4 >>> | stack pointer = 0x10:0xffffffffae39faf0 >>> | frame pointer = 0x10:0xf85ecc37f9239402 >>> | code segment = base 0x0, limit 0xfffff, type 0x1b >>> | = DPL 0, pres 1, long 1, def32 0, gran 1 >>> | processor eflags = interrupt enabled, resume, IOPL = 0 >>> | current process = 27 (em0 taskq) >>> | trap number = 27 >>> | panic: stack fault >>> | cpuid = 0 >>> | Uptime: 43m44s >>> | Physical memory: 4082 MB >>> | Dumping 361 MB: 346 330 314 298 282 266 250 234 218 202em0: >>> watchdog timeout -- resetting >>> >>> | (kgdb) bt >>> | #0 doadump () at pcpu.h:195 >>> | #1 0x0000000000000004 in ?? () >>> | #2 0xffffffff804bd9b9 in boot (howto=260) at /usr/src/sys/kern/ >>> kern_shutdown.c:418 >>> | #3 0xffffffff804bddc2 in panic (fmt=0x104
>> bounds>) at /usr/src/sys/kern/kern_shutdown.c:574 >>> | #4 0xffffffff807b9f23 in trap_fatal (frame=0xffffff00012d66e0, >>> eva=Variable "eva" is not available. >>> | ) at /usr/src/sys/amd64/amd64/trap.c:764 >>> | #5 0xffffffff807baa75 in trap (frame=0xffffffffae39fa40) at /usr/ >>> src/sys/amd64/amd64/trap.c:565 >>> | #6 0xffffffff807a042e in calltrap () at /usr/src/sys/amd64/amd64/ >>> exception.S:209 >>> | #7 0xffffffff80559fb4 in ether_input (ifp=0xffffff00012bf000, >>> m=0xffffff0003576000) at /usr/src/sys/net/if_ethersubr.c:545 >>> | #8 0xffffffff802bd645 in em_rxeof (adapter=0xffffffff80e4c000, >>> count=99) at /usr/src/sys/dev/e1000/if_em.c:4539 >>> | #9 0xffffffff802be55e in em_handle_rxtx (context=Variable >>> "context" is not available. >>> | ) at /usr/src/sys/dev/e1000/if_em.c:1702 >>> | #10 0xffffffff804f2afd in taskqueue_run (queue=0xffffff00012c8c80) >>> at /usr/src/sys/kern/subr_taskqueue.c:282 >>> | #11 0xffffffff804f2da6 in taskqueue_thread_loop (arg=Variable >>> "arg" is not available. >>> | ) at /usr/src/sys/kern/subr_taskqueue.c:401 >>> | #12 0xffffffff8049b2f3 in fork_exit (callout=0xffffffff804f2d40 >>> , arg=0xffffffff80e50588, >>> frame=0xffffffffae39fc80) at /usr/src/sys/kern/kern_fork.c:804 >>> | #13 0xffffffff807a07fe in fork_trampoline () at /usr/src/sys/ >>> amd64/ >>> amd64/exception.S:455 >>> | #14 0x0000000000000000 in ?? () >>> | #15 0x0000000000000000 in ?? () >>> | #16 0x0000000000000001 in ?? () >>> [...] >>> >>> | (kgdb) source debug/gdb6 >>> | (kgdb) frame 7 >>> | #7 0xffffffff80559fb4 in ether_input (ifp=0xffffff00012bf000, >>> m=0xffffff0003576000) at /usr/src/sys/net/if_ethersubr.c:545 >>> | 545 eh = mtod(m, struct ether_header *); >>> | (kgdb) info locals >>> | eh = (struct ether_header *) 0xf85ecc37f9239402 >>> | (kgdb) info args >>> | ifp = (struct ifnet *) 0xffffff00012bf000 >>> | m = (struct mbuf *) 0xffffff0003576000 >>> | (kgdb) mbuf m >>> | 0xffffff0003576000: 125 bytes ext 0xaf29dcb45d53e701 packet: 125 >>> bytes received via em0 >>> | 0xbb763383e10eda22Cannot access memory at address >>> 0xbb763383e10eda3a >>> | (kgdb) >>> >>> If anyone can provide some points on other things I can try to get >>> useful data out of these core dumps, I'm open to it. >>> >>> We did decide to stop mounting NFS, upgrade to syslog-ng3 (which >>> supports TLS), and revert the webserver back to a GENERIC kernel. >>> Since >>> booting the GENERIC kernel, the system has been up for nearly 2 >>> days. >>> >>> Right now, we're logging via TLS to a temporary/testing logserver. >>> That >>> logserver is one of our default builds with IPSec. It is >>> configured to >>> forward logs over udp/syslog (via IPSec in transport mode) to our >>> primary logserver. >>> >>> Within hours of beginning to pass the production webserver's logs >>> through this temporary logserver (and thus having its syslog-ng >>> forward >>> to the primary logserver), the temporary logserver began exhibiting >>> the >>> same behavior that the webserver was previously showing. >>> >>> We're totally grasping at straws here, but it's looking like some >>> kind >>> of bug related to IPSec. Maybe related to long messages? High volume >>> of >>> messages? >>> >>> We would love to get this hammered out, so please let me know if >>> there's >>> any debugging we can perform or patches we can try. >>> >> >> Hi Chris, >> >> Sorry to hear y'all are having problems. You mention that you >> switched to GENERIC? Can you send out a copy of your modified kernel >> config? I'm a bit confused because the kernel panic you do show >> looks like it's from a GENERIC kernel. > > Sorry, the uname was from a stable boot after we had switched to > GENERIC. > > The config from the crashing kernel: > > | include GENERIC > | > | ident RCBSD_REL7 > | > | # Enabling IPSec (see SysAdmin.IPSec in TWiki) > | options IPSEC > | options IPSEC_FILTERTUNNEL > | device crypto > | > | # Enabling quota support > | options QUOTA > >> Are you setting any of the em device's kernel tunables? > > Nope. Some more details on the hardware: > > | [ccowart@mug /usr/local/rescomp/etc/online-helpdesk]$ dmesg | grep > em0 > | em0: port > 0xece0-0xecff mem 0xfc3e0000-0xfc3fffff,0xfc3c0000-0xfc3dffff irq 16 > at device 0.0 on pci14 > | em0: Using MSI interrupt > | em0: [FILTER] > | em0: Ethernet address: 00:15:17:7a:b5:e0 > | em0: link state changed to UP > >> How is your IPSEC stuff built in to the kernel and are you setting >> any >> kernel variables for it? > > See the kernel config above. We are not tuning via sysctls or the > loader.conf. All of that should be stock for IPSEC. The host is > configured with 2 peers for IPSec communication. We use racoon and > x509 > certificates. > >> My best guess from the stack trace is a buffer that is not being >> returned properly somewhere between the device and the IPsec >> subsystem. > > One of my coworkers has been able to reproduce the crash by syslogging > really long lines. I'm planning to spend some time today to try to > create a smaller example case on a couple of vms. Sounds great. One more thought. Can you try this without IPSEC_FILTERTUNNEL? Since that copies packets I'm suspicious of it. Best, George From owner-freebsd-net@FreeBSD.ORG Tue Sep 8 16:15:29 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99BA3106568B for ; Tue, 8 Sep 2009 16:15:29 +0000 (UTC) (envelope-from stef-list@memberwebs.com) Received: from mail.npubs.com (mail.npubs.com [74.82.45.72]) by mx1.freebsd.org (Postfix) with ESMTP id 8C3D38FC13 for ; Tue, 8 Sep 2009 16:15:29 +0000 (UTC) Resent-Message-Id: From: Stef Walter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Bruce Simpson References: <4AA65663.8050106@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Resent-Date: Tue, 8 Sep 2009 16:15:29 +0000 (UTC) Resent-From: stef-list@memberwebs.com Cc: "freebsd-net@FreeBSD.org" Subject: Re: Panic in imo_match_source (netinet/in_mcast.c) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stef@memberwebs.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 08 Sep 2009 16:15:29 -0000 X-List-Received-Date: Tue, 08 Sep 2009 16:15:29 -0000 Bruce Simpson wrote: > Full OS version, dmesg, panic and backtrace please, when reporting this > kind of issue... otherwise folk can't help. Thanks for taking a look. It was linked in the parent post: > This is the stack trace: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/137164&cat= > Are you using SSM multicast > features? Not that I know of. This is IPv4 OSPF which as far as I know sends simple multicast to 224.0.0.5. I'm using quagga 0.99.15 to run OSPF. Cheers, Stef From owner-freebsd-net@FreeBSD.ORG Tue Sep 8 16:15:30 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46D191065692 for ; Tue, 8 Sep 2009 16:15:30 +0000 (UTC) (envelope-from stef-list@memberwebs.com) Received: from mail.npubs.com (mail.npubs.com [74.82.45.72]) by mx1.freebsd.org (Postfix) with ESMTP id 38BA38FC19 for ; Tue, 8 Sep 2009 16:15:30 +0000 (UTC) Resent-Message-Id: From: Stef Walter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Bruce Simpson References: <4AA65663.8050106@incunabulum.net> <4AA65861.8@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Resent-Date: Tue, 8 Sep 2009 16:15:30 +0000 (UTC) Resent-From: stef-list@memberwebs.com Cc: "freebsd-net@FreeBSD.org" Subject: Re: Panic in imo_match_source (netinet/in_mcast.c) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stef@memberwebs.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 08 Sep 2009 16:15:30 -0000 X-List-Received-Date: Tue, 08 Sep 2009 16:15:30 -0000 Bruce Simpson wrote: > [Brief reply as I'm meant to be doing a zillion other things...] > > Bruce Simpson wrote: >> >> Full OS version, dmesg, panic and backtrace please, when reporting >> this kind of issue... otherwise folk can't help. Are you using SSM >> multicast features? > > P.S. You might want to try demoting the KASSERT to a conditional error > return (return no match if src is NULL or src->sa_family != AF_INET), > and see if that fix 'just works' for you. Sometimes the asserts I > sprinkle into code are too paranoid for what's going on, and syrinx@ > recently caught one of those. Yes, I patched that out and have been testing. However in this case OSPF (quagga) stops running. Maybe quagga is doing something unexpected. I've been slowly trying to corner this issue. Cheers, Stef From owner-freebsd-net@FreeBSD.ORG Tue Sep 8 16:15:31 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34FBA1065694 for ; Tue, 8 Sep 2009 16:15:31 +0000 (UTC) (envelope-from stef-list@memberwebs.com) Received: from mail.npubs.com (mail.npubs.com [74.82.45.72]) by mx1.freebsd.org (Postfix) with ESMTP id 259848FC1B for ; Tue, 8 Sep 2009 16:15:31 +0000 (UTC) Resent-Message-Id: From: Stef Walter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Shteryana Shopova References: <4AA65663.8050106@incunabulum.net> <4AA65861.8@incunabulum.net> <61b573980909080654x50670168x39001267ad81c6a3@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Resent-Date: Tue, 8 Sep 2009 16:15:31 +0000 (UTC) Resent-From: stef-list@memberwebs.com Cc: "freebsd-net@FreeBSD.org" , Bruce Simpson Subject: Re: Panic in imo_match_source (netinet/in_mcast.c) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stef@memberwebs.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 08 Sep 2009 16:15:31 -0000 X-List-Received-Date: Tue, 08 Sep 2009 16:15:31 -0000 Shteryana Shopova wrote: > I actually managed to get the same kernel dump using the following > sample code - http://people.freebsd.org/~syrinx/mcast/mcast_crash.c > and the crash is 100% reproducable. A temporary fix is here - > http://people.freebsd.org/~syrinx/mcast/in_mcast.c-20090908-01.diff > but I actually prefer that we go over the logic in inp_join_group() > again before proposing a patch for head as this is the second assert > panic I am seeing it causes in the last few days. I can try making up > a proper fix if Bruce is busy, but it will take a day or two until I'm > able to fully test it. Hmmmm, EADDRINUSE ... This sounds very familiar. Here's an old quagga bug that I don't think got patched properly. It does an unexpected double IP_ADD_MEMBERSHIP: http://bugzilla.quagga.net/show_bug.cgi?id=212 I'll test the patch here. Thanks! Cheers, Stef From owner-freebsd-net@FreeBSD.ORG Tue Sep 8 18:03:16 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C08F106568D; Tue, 8 Sep 2009 18:03:16 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 337AA8FC15; Tue, 8 Sep 2009 18:03:16 +0000 (UTC) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n88I3Gng036809; Tue, 8 Sep 2009 18:03:16 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n88I3GBB036805; Tue, 8 Sep 2009 18:03:16 GMT (envelope-from linimon) Date: Tue, 8 Sep 2009 18:03:16 GMT Message-Id: <200909081803.n88I3GBB036805@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/138620: [lagg] [patch] lagg port bpf-writes blocked X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 18:03:16 -0000 Old Synopsis: lagg port bpf-writes blocked New Synopsis: [lagg] [patch] lagg port bpf-writes blocked Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Sep 8 18:02:22 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138620 From owner-freebsd-net@FreeBSD.ORG Tue Sep 8 18:09:35 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99DE7106568B; Tue, 8 Sep 2009 18:09:35 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 71A918FC18; Tue, 8 Sep 2009 18:09:35 +0000 (UTC) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n88I9Z4X037164; Tue, 8 Sep 2009 18:09:35 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n88I9ZRt037160; Tue, 8 Sep 2009 18:09:35 GMT (envelope-from linimon) Date: Tue, 8 Sep 2009 18:09:35 GMT Message-Id: <200909081809.n88I9ZRt037160@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/138632: [ndis] [patch] race at vap destroy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 18:09:35 -0000 Old Synopsis: race at vap destroy New Synopsis: [ndis] [patch] race at vap destroy Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Sep 8 18:08:44 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138632 From owner-freebsd-net@FreeBSD.ORG Tue Sep 8 18:39:37 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30EB71065670; Tue, 8 Sep 2009 18:39:37 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from no.spam.no.ddos.ru (no.spam.no.ddos.ru [77.73.233.132]) by mx1.freebsd.org (Postfix) with ESMTP id B1A0E8FC16; Tue, 8 Sep 2009 18:39:36 +0000 (UTC) Received: from ws.ipfw.ru (secured.by.ipfw.ru [81.200.11.182]) by no.spam.no.ddos.ru (Postfix) with ESMTPA id 171A837B1D8; Tue, 8 Sep 2009 18:39:32 +0000 (UTC) Message-ID: <4AA6A4C8.4090200@ipfw.ru> Date: Tue, 08 Sep 2009 22:39:04 +0400 From: "Alexander V. Chernikov" User-Agent: Thunderbird 2.0.0.22 (X11/20090818) MIME-Version: 1.0 To: grarpamp References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-isp@freebsd.org, freebsd-net@freebsd.org Subject: Re: Call for testers: ng_netflow with v9 and IPv6 support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 18:39:37 -0000 grarpamp wrote: > Wouldn't it be better to support the obvious formal emergent standards > track protocol instead of the legacy informational one? Or to perform > both via sysctl or other arguments/defines, with the standard IPFIX > being the default mode? Have you reviewed the nProbe code for other > various ideas? Thanks for working on netflow :) And any form of v6 > is good to have finally. > Thanks for pointing out those RFCs. We're still using v5 for accounting, so my behavior was quite straightforward: can v5 count ipv6 ? No, what's next netflow version can ? v9? Ok, let's implement v9. However, IPFIX seems to be very much like v9 at a first glance. Moreover, ng_ksocket can handle udp/tcp/sctp exports. > ========================================================================= > > Network Working Group B. Claise, Ed. > Request for Comments: 5101 Cisco Systems, Inc. > Category: Standards Track January 2008 > Specification of the IP Flow Information Export (IPFIX) Protocol > for the Exchange of IP Traffic Flow Information > This document specifies an Internet standards track protocol for the > Internet community > > > Network Working Group J. Quittek > Request for Comments: 5102 NEC > Category: Standards Track S. Bryant > B. Claise > P. Aitken > Cisco Systems, Inc. > J. Meyer > PayPal > January 2008 > Information Model for IP Flow Information Export > This document specifies an Internet standards track protocol for the > Internet community > > > Network Working Group B. Trammell > Request for Comments: 5103 CERT/NetSA > Category: Standards Track E. Boschi > Hitachi Europe > January 2008 > Bidirectional Flow Export Using IP Flow Information Export (IPFIX) > This document specifies an Internet standards track protocol for the > Internet community > > > Network Working Group E. Boschi > Request for Comments: 5153 Hitachi Europe > Category: Informational L. Mark > Fraunhofer FOKUS > J. Quittek > M. Stiemerling > NEC > P. Aitken > Cisco Systems, Inc. > April 2008 > IP Flow Information Export (IPFIX) Implementation Guidelines > This memo provides information for the Internet community. It does > not specify an Internet standard of any kind. > > > Network Working Group S. Leinen > Request for Comments: 3955 SWITCH > Category: Informational October 2004 > Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX) > This memo provides information for the Internet community. It does > not specify an Internet standard of any kind. > > > Network Working Group J. Quittek > Request for Comments: 3917 NEC Europe Ltd. > Category: Informational T. Zseby > Fraunhofer FOKUS > B. Claise > Cisco Systems > S. Zander > Swinburne University > October 2004 > Requirements for IP Flow Information Export (IPFIX) > This memo provides information for the Internet community. It does > not specify an Internet standard of any kind. > > > And others... > > ========================================================================= > > Network Working Group B. Claise, Ed. > Request for Comments: 3954 Cisco Systems > Category: Informational October 2004 > Cisco Systems NetFlow Services Export Version 9 > This RFC documents the NetFlow services export protocol Version 9 as > it was when submitted to the IETF as a basis for further work in the > IPFIX WG. > This RFC itself is not a candidate for any level of Internet > Standard. The IETF disclaims any knowledge of the fitness of this > RFC for any purpose... > > And others... > > ========================================================================= > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Sep 8 20:39:51 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 604FE1065693; Tue, 8 Sep 2009 20:39:51 +0000 (UTC) (envelope-from weongyo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 387F98FC12; Tue, 8 Sep 2009 20:39:51 +0000 (UTC) Received: from freefall.freebsd.org (weongyo@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n88KdpT0088590; Tue, 8 Sep 2009 20:39:51 GMT (envelope-from weongyo@freefall.freebsd.org) Received: (from weongyo@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n88KdpDQ088586; Tue, 8 Sep 2009 20:39:51 GMT (envelope-from weongyo) Date: Tue, 8 Sep 2009 20:39:51 GMT Message-Id: <200909082039.n88KdpDQ088586@freefall.freebsd.org> To: weongyo@FreeBSD.org, freebsd-net@FreeBSD.org, weongyo@FreeBSD.org From: weongyo@FreeBSD.org Cc: Subject: Re: kern/138292: [zyd] [usb8] "zyd0: device timeout" with ZyXEL G-202 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 20:39:51 -0000 Synopsis: [zyd] [usb8] "zyd0: device timeout" with ZyXEL G-202 Responsible-Changed-From-To: freebsd-net->weongyo Responsible-Changed-By: weongyo Responsible-Changed-When: Tue Sep 8 20:39:37 UTC 2009 Responsible-Changed-Why: grap. http://www.freebsd.org/cgi/query-pr.cgi?pr=138292 From owner-freebsd-net@FreeBSD.ORG Tue Sep 8 21:34:33 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0897C1065670 for ; Tue, 8 Sep 2009 21:34:33 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 603598FC19 for ; Tue, 8 Sep 2009 21:34:32 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so950130qwe.7 for ; Tue, 08 Sep 2009 14:34:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:subject :message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=W0U+4Cjx34Q2/qBMo4SzPvN+U4Ya/waJyy4GaHd/Xns=; b=alQ7RppKAB54r2gtaHHtdRRCAK7c82O9BUqvE41o53TuKbfZXfKYd1q4zylN4jzjcU l0KCTL+rr3PXw6P3X0VkfpFHi2Iq/R//088wt7KmIuqiuM7/7b9aVCAvysP7Ne1Ub+KP 7j0zP/IfSM2QsCZMLBDm0kIaP6S9l6iTlS5O8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=lI6Qymbupg0KMfoqNydH+l+O9ERfg4hVvXVyPh4uE4iykcuwtcQCP0dpdV2m8gaYP9 kSdd6V+iBpt3qxz3NZ/LX/IXoz+mokrAxwNfruV687g3apemsJdB86EN/gc6z/abGc7m 5w+fs2GOFC5p65bK9Vi47vq/+hh3S0DmQ+X4E= Received: by 10.224.117.212 with SMTP id s20mr10485629qaq.95.1252445671517; Tue, 08 Sep 2009 14:34:31 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 6sm18139qwd.43.2009.09.08.14.34.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 08 Sep 2009 14:34:30 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 8 Sep 2009 14:33:35 -0700 From: Pyun YongHyeon Date: Tue, 8 Sep 2009 14:33:35 -0700 To: freebsd-net@freebsd.org Message-ID: <20090908213335.GE1520@michelle.cdnetworks.com> References: <20090821221932.GE1262@michelle.cdnetworks.com> <20090825083857.GA22983@traktor.dnepro.net> <20090825114649.GA11642@traktor.dnepro.net> <20090825130821.GA41669@traktor.dnepro.net> <20090825182553.GD1282@michelle.cdnetworks.com> <20090826093916.GB10790@traktor.dnepro.net> <20090826094856.GC10790@traktor.dnepro.net> <20090901161310.GA37481@traktor.dnepro.net> <20090904212223.GA9950@michelle.cdnetworks.com> <20090908075030.GA6644@traktor.dnepro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090908075030.GA6644@traktor.dnepro.net> User-Agent: Mutt/1.4.2.3i Subject: Re: D-Link DGE-560SX (Marvell 88E8061-based) doesn't see link X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 21:34:33 -0000 On Tue, Sep 08, 2009 at 10:50:30AM +0300, Eugene Perevyazko wrote: > On Fri, Sep 04, 2009 at 02:22:23PM -0700, Pyun YongHyeon wrote: > > > > Would you back out previous changes and apply the patch at the > > following URL? > > http://people.freebsd.org/~yongari/msk/msk.DGE560.diff2 > > > > Note, I have no more access to msk(4) hardwares so it wasn't tested > > at all except compilation. > > > > Still no success. > > mskc0: port 0xd800-0xd8ff mem 0xfeafc000-0xfeafffff irq 16 at device 0.0 on pci1 > msk0: on mskc0 > msk0: Ethernet address: 00:21:91:52:4f:09 > miibus0: on msk0 > e1000phy0: PHY 0 on miibus0 > e1000phy0: 1000baseSX, 1000baseSX-FDX, auto > mskc0: [FILTER] > > ifconfig -m msk0 > msk0: flags=8843 metric 0 mtu 1500 > options=11a > capabilities=11a > ether 00:21:91:52:4f:09 > inet 10.2.3.1 netmask 0xffffff00 broadcast 10.2.3.255 > media: Ethernet autoselect (autoselect ) > status: active > supported media: > media autoselect > media 1000baseSX mediaopt full-duplex > media 1000baseSX > media none > > Switch shows no link on the port. > > # ifconfig msk0 media 1000baseSX mediaopt full-duplex > # ifconfig msk0 > msk0: flags=8843 metric 0 mtu 1500 > options=11a > ether 00:21:91:52:4f:09 > inet 10.2.3.1 netmask 0xffffff00 broadcast 10.2.3.255 > media: Ethernet 1000baseSX (autoselect ) > status: active > > Switch shows no link again. > > All dev.msk.0.stats counters are zero even after trying broadcast ping. > > I can arrange you root access to the host with this NIC if you have time/wish. > I've sent mail in private. > -- > Eugene Perevyazko From owner-freebsd-net@FreeBSD.ORG Tue Sep 8 21:42:40 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D50B1065670 for ; Tue, 8 Sep 2009 21:42:40 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63904.mail.re1.yahoo.com (web63904.mail.re1.yahoo.com [69.147.97.119]) by mx1.freebsd.org (Postfix) with SMTP id D754F8FC20 for ; Tue, 8 Sep 2009 21:42:39 +0000 (UTC) Received: (qmail 44988 invoked by uid 60001); 8 Sep 2009 21:42:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1252446159; bh=oXv/q1uxwPOClHHdgTilGBS/T6I+ursjoPhQK0sZhck=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=OQrPVI6yoMZ2FB+gTfmquW6h0iTCu0/RIFb0QPz56cd4T9CieCCXVWWYFDUJSPq0nFWvr5kYr3aJPu1DFOjFP7XoAOR7zjboyouW8iGjSqU/T7ekxmhpckaB3ZpE0QkydN7O3kXXgDWApDuOfLaEM3y9qM9CQiasUazAB/Oq7II= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=J3WKpG6kHJvdoGURK25q9KzCFL4dPTkXswCCboVDN4mjOB+bpHH9IaQG6RhmN0IAwvZ7BoamUSjL6HOtdyLkirdMEhwUAuLXiEmgAX1jCEOPAB7QzzJ5UbwyVsa8N5OF3AdSzlH5SUbVk1eFXELcBkBpnjFugT1aRRmasycK/Ik=; Message-ID: <324031.44935.qm@web63904.mail.re1.yahoo.com> X-YMail-OSG: UszZVoYVM1m3RegbJlCsbRs2gA_R_nnAt5jHRsY5CLIfkeAmx6dcin1bWAKcrmrQ5Z4pz5uNYrixvnL8joJTjegmwAqueOxE_nF.m9XWx5Z8_EFYFarz0eZ8CIETqwOgbrCD8TO7KsrwuVMlyzHscn2i8pvFixw8JXq1vEsvU4cMoC36075vM3okuyaXRw.1n4MBCcuDOjO.4XfdCu0r4ihMDCVDUlw.YFiV87GRlc8YejZ2pCyY.V0bcxaN1WQGIc6wLEjPWFN_A3KOoVqkJ0M- Received: from [98.203.21.152] by web63904.mail.re1.yahoo.com via HTTP; Tue, 08 Sep 2009 14:42:39 PDT X-Mailer: YahooMailClassic/6.1.2 YahooMailWebService/0.7.338.2 Date: Tue, 8 Sep 2009 14:42:39 -0700 (PDT) From: Barney Cordoba To: alexpalias-bsdnet@yahoo.com, Manish Vachharajani In-Reply-To: <5bc218350909041041x49ec9765k81346e90bbfe891a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Artis Caune Subject: Re: em driver input errors X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 21:42:40 -0000 =0A=0A--- On Fri, 9/4/09, Manish Vachharajani = wrote:=0A=0A> From: Manish Vachharajani =0A> = Subject: Re: em driver input errors=0A> To: alexpalias-bsdnet@yahoo.com=0A>= Cc: freebsd-net@freebsd.org, "Artis Caune" =0A> Dat= e: Friday, September 4, 2009, 1:41 PM=0A> Just decided to follow this threa= d as=0A> it seems to be related to some=0A> issues we are seeing as well.= =0A> =0A> It appears that under heavy packet loads, the kernel cannot=0A> p= ull=0A> packets off the NIC fast enough and thus is slow to free=0A> up=0A>= descriptors into which the NIC can DMA packets.=A0 This=0A> causes the NIC= =0A> to drop the packet after it's internal queue fills up (and=0A> record = the=0A> packet as missed) because the hardware does not have=0A> enough=0A>= descriptors to write the packets into.=A0 We ahve this=0A> issue with the= =0A> ixgbe 10 Gb/s card though the absolute packet rates at=0A> which we se= e a=0A> problem are higher than those reported here.=0A> =0A> In our test s= cenario the problem gets worse with many=0A> simultaneous TCP=0A> connectio= ns, but the issue is the same.=A0 Under high=0A> packet rates, the=0A> driv= er cannot keep up and the NIC reports missed=0A> packets.=A0 The issue=0A> = is not related to data throughput though as turning on=0A> jumbo frames=0A>= solves our issue for a fixed number of connections, and it=0A> seems here= =0A> that reducing the packet rate makes the misses go=0A> away.=A0 More=0A= > importantly, in our tests, only the receiver sees a=0A> problem, the=0A> = transmitter is fine.=0A> =0A> There was also another thread about problems = with UDP=0A> throughput that=0A> I suspect are caused by the same type of p= acket rate=0A> spikes.=0A> =0A> The question is, why is the kernel stack sl= ow to handle=0A> these packet=0A> rates, doing some back of the envelope ca= lculations, they=0A> don't seem=0A> too bad?=A0 Where is the time going?=A0= And, are our=0A> problem, the UDP=0A> issue, and this problem all caused b= y the same source of=0A> slowness or=0A> are they three unrelated issues.= =0A> =0A> Manish=0A=0AWhat specific kinds of input errors are you getting?= =0A=0AHow many PPS are you doing, what is the size of the ring, and=0Athe i= nterrupt modulation rate?=0A=0AAre the NICs PCIe or PCIx?=0A=0ABarney=0A=0A= =0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Tue Sep 8 22:21:38 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA60D1065670 for ; Tue, 8 Sep 2009 22:21:38 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 695258FC1C for ; Tue, 8 Sep 2009 22:21:37 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n88MI7TH073975; Tue, 8 Sep 2009 18:18:07 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200909082218.n88MI7TH073975@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 08 Sep 2009 18:21:33 -0400 To: Barney Cordoba From: Mike Tancsa In-Reply-To: <324031.44935.qm@web63904.mail.re1.yahoo.com> References: <5bc218350909041041x49ec9765k81346e90bbfe891a@mail.gmail.com> <324031.44935.qm@web63904.mail.re1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: em driver input errors X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 22:21:39 -0000 At 05:42 PM 9/8/2009, Barney Cordoba wrote: >Manish What specific kinds of input errors are you getting? How many >PPS are you doing, what is the size of the ring, and the interrupt >modulation rate? Are the NICs PCIe or PCIx? Barney In my case, our backup server (mix of dump via nfs and some dumps through ssh as well as writes via samba mounts) has a fairly low pps rate and starts to see input errors at about 100Mb. Adding hw.em.rxd=4096 hw.em.txd=4096 and net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.recvspace=131072 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.sendspace=131072 net.inet.udp.recvspace=65536 kern.ipc.somaxconn=1024 kern.ipc.maxsockbuf=4194304 net.inet.ip.redirect=0 net.inet.ip.intr_queue_maxlen=4096 net.route.netisr_maxqlen=1024 kern.ipc.nmbclusters=655360 didnt seem to make a difference in the amount of errors I was seeing em1@pci0:7:5:0: class=0x020000 card=0x348f8086 chip=0x10768086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (82541EI)' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction Core(TM)2 Quad CPU Q6600 @ 2.40GHz, AMD64, RELENG_7 from Jun 18th Plenty of disk IO left and the CPUs doent seem to be taxed that much. Sep 8 00:02:01 backup3 kernel: em1: Excessive collisions = 0 Sep 8 00:02:01 backup3 kernel: em1: Sequence errors = 0 Sep 8 00:02:01 backup3 kernel: em1: Defer count = 0 Sep 8 00:02:01 backup3 kernel: em1: Missed Packets = 61316 Sep 8 00:02:01 backup3 kernel: em1: Receive No Buffers = 0 Sep 8 00:02:01 backup3 kernel: em1: Receive Length Errors = 0 Sep 8 00:02:01 backup3 kernel: em1: Receive errors = 0 Sep 8 00:02:01 backup3 kernel: em1: Crc errors = 0 Sep 8 00:02:01 backup3 kernel: em1: Alignment errors = 0 Sep 8 00:02:01 backup3 kernel: em1: Collision/Carrier extension errors = 0 Sep 8 00:02:01 backup3 kernel: em1: RX overruns = 22397 Sep 8 00:02:01 backup3 kernel: em1: watchdog timeouts = 0 Sep 8 00:02:01 backup3 kernel: em1: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 Sep 8 00:02:01 backup3 kernel: em1: XON Rcvd = 0 Sep 8 00:02:01 backup3 kernel: em1: XON Xmtd = 0 Sep 8 00:02:01 backup3 kernel: em1: XOFF Rcvd = 0 Sep 8 00:02:01 backup3 kernel: em1: XOFF Xmtd = 0 Sep 8 00:02:01 backup3 kernel: em1: Good Packets Rcvd = 544276980 Sep 8 00:02:01 backup3 kernel: em1: Good Packets Xmtd = 490475071 Sep 8 00:02:01 backup3 kernel: em1: TSO Contexts Xmtd = 0 Sep 8 00:02:01 backup3 kernel: em1: TSO Contexts Failed = 0 pf is in the kernel as well >_______________________________________________ >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" -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-net@FreeBSD.ORG Wed Sep 9 02:05:15 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 919C21065672; Wed, 9 Sep 2009 02:05:15 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id F37D58FC17; Wed, 9 Sep 2009 02:05:14 +0000 (UTC) Received: by fxm6 with SMTP id 6so2936005fxm.43 for ; Tue, 08 Sep 2009 19:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=noSEXORYk0fqpv880QgYGo33AVnJQC+JytP50QbDLMk=; b=WF+E9WDfezTAmFvbfpoU3aofr1XuW2HLtW98ZTYMJnNFKbGeQS79HlxEt9IOSrgMPQ cwAY6INhztXvksDTSLax7DdIFli15Q87fx97xX4zcyoOb74rV4Zpj5ivP+FkwuE7orjH Rl77v//cw+CPJ1DomLoxVc3QmoVXG7STIRy9A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=sqa56HRdipYgsB+ecviBupimlKg/tKwbu8xxkqksP2BvGJNFzopl3BS5ux7Bji3u1h /GG8T17gXuy6Q9bDu4WfZa1VkidQ1Q2IDy80yVlzw1fnOxcAd2pryY+enn9OOLT52o1Z 0isDH5iy9s1Rv6BnQCCR8boW3De7HeO3Vnkfg= MIME-Version: 1.0 Received: by 10.223.1.10 with SMTP id 10mr6374037fad.94.1252461913243; Tue, 08 Sep 2009 19:05:13 -0700 (PDT) In-Reply-To: <4AA6A4C8.4090200@ipfw.ru> References: <4AA6A4C8.4090200@ipfw.ru> Date: Tue, 8 Sep 2009 22:05:13 -0400 Message-ID: From: grarpamp To: freebsd-net@freebsd.org, freebsd-isp@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: Call for testers: ng_netflow with v9 and IPv6 support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 02:05:15 -0000 > Thanks for pointing out those RFCs. Sure. There are more I probably missed. Search rfc-editor or ietf for netflow or ipfix. > can v5 count ipv6 ? No, what's next netflow version can ? v9? Ok, let's > implement v9. Yep, ipv6 is becoming really important, definitely on backbones. nProbe has had it for a while. nProbe is a bpf flow sniffer and exporter. I don't know about any other open source ones that do, besides your patch :) > However, IPFIX seems to be very much like v9 at a first glance. v9 was the first that came out, mostly a defacto cisco proprietary thing as was v5. Netflow needed to be opened up / standardized. So ipfix group was started. cisco v9 was submitted to ietf ipfix working group as one of proposed ipfix methods. v9 was then modified in the group a bit and called IPFIX. Some of this is in rfc 3955. Ipfix is probably the way to go. Of course others on the lists could input whether they see more of v9 or ipfix now and in future. From owner-freebsd-net@FreeBSD.ORG Wed Sep 9 03:37:34 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C75791065692 for ; Wed, 9 Sep 2009 03:37:34 +0000 (UTC) (envelope-from stef-list@memberwebs.com) Received: from mail.npubs.com (mail.npubs.com [74.82.45.72]) by mx1.freebsd.org (Postfix) with ESMTP id A6DA18FC1C for ; Wed, 9 Sep 2009 03:37:34 +0000 (UTC) Resent-Message-Id: From: Stef Walter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "freebsd-net@FreeBSD.org" Content-Type: multipart/mixed; boundary="------------040206040408060908060700" X-Virus-Scanned: ClamAV using ClamSMTP Resent-Date: Wed, 9 Sep 2009 03:37:34 +0000 (UTC) Resent-From: stef-list@memberwebs.com Subject: [patch] Multicast: IP_DROP_MEMBERSHIP should return EADDRNOTAVAIL for invalid address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stef@memberwebs.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 09 Sep 2009 03:37:35 -0000 X-List-Received-Date: Wed, 09 Sep 2009 03:37:35 -0000 This is a multi-part message in MIME format. --------------040206040408060908060700 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit After an interface goes down and its addresses go away, if a caller calls setsockopt/IP_DROP_MEMBERSHIP with a simple in_mreq input containing the address that no longer exists, the kernel should return EADDRNOTAVAIL. However the current behavior in 8.0-BETA3 is to remove a membership to the same multicast group from the 'first' interface instead. You can see the results below in the ifmcstat output below. Before northstar1 (tunnel) interface goes away, both bge0 and northstar1 are on the 224.0.0.5 (ie: OSPF-ALL.MCAST.NET) group. > bge0: > inet 172.27.5.18 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.5 mode exclude > mcast-macaddr 01:00:5e:00:00:05 > group 224.0.0.1 mode exclude > mcast-macaddr 01:00:5e:00:00:01 > rl0: > inet 192.168.1.70 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.1 mode exclude > mcast-macaddr 01:00:5e:00:00:01 > lo0: > inet 127.0.0.1 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.1 mode exclude > inet6 fe80::1%lo0 > mldv2 flags=0<> rv 2 qi 125 qri 10 uri 3 > group ff01::1%lo0 mode exclude > group ff02::2:e78c:f513%lo0 mode exclude > group ff02::1%lo0 mode exclude > group ff02::1:ff00:1%lo0 mode exclude > northstar1: > inet 172.28.1.66 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.5 mode exclude > group 224.0.0.1 mode exclude After northstar1 goes down, and setsockopt(..., IP_DROP_MEMBERSHIP, ...) is called for the 172.28.1.66 address, we see that the group has been dropped from bge0 instead. No error was returned from setsockopt. > bge0: > inet 172.27.5.18 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.1 mode exclude > mcast-macaddr 01:00:5e:00:00:01 > rl0: > inet 192.168.1.70 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.1 mode exclude > mcast-macaddr 01:00:5e:00:00:01 > lo0: > inet 127.0.0.1 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.1 mode exclude > inet6 fe80::1%lo0 > mldv2 flags=0<> rv 2 qi 125 qri 10 uri 3 > group ff01::1%lo0 mode exclude > group ff02::2:e78c:f513%lo0 mode exclude > group ff02::1%lo0 mode exclude > group ff02::1:ff00:1%lo0 mode exclude > northstar1: UNAME: FreeBSD portillo-gate.ws.local 8.0-BETA3 FreeBSD 8.0-BETA3 #19: Wed Sep 9 01:27:39 UTC 2009 root@portillo-gate.ws.local:/usr/src/sys/i386/compile/PORTILLO i386 Patch is attached which fixes the problem. Is this the right approach? BTW, the behavior of FreeBSD has always been that after northstar1 comes back up with the same address, it is a member of 224.0.0.5 group. Memberships are retained across interfaces and addresses going away. Not sure if this is the best behavior, but it has been the historical behavior. One can see people coding against this in routing software [2]. Besides fixing the problem of dropping membership on the first interface, the effect of this patch is to restore the previous freebsd behavior. Cheers, Stef PS: BTW, I've been using the patch [1] for the imo_match_source panic, that Shteryana posted. That fixes problems calling IP_ADD_MEMBERSHIP twice with the same info. [1] http://people.freebsd.org/~syrinx/mcast/in_mcast.c-20090908-01.diff [2] http://code.quagga.net/cgi-bin/gitweb.cgi?p=quagga.git;a=blob;f=lib/sockopt.c;h=55c6226b711e6386ef0378eb6def992af281082e;hb=HEAD#l196 --------------040206040408060908060700 Content-Type: text/x-diff; name="freebsd-mcast-drop-eaddrnotavail.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="freebsd-mcast-drop-eaddrnotavail.patch" --- sys/netinet/in_mcast.c.orig 2009-08-03 08:13:06.000000000 +0000 +++ sys/netinet/in_mcast.c 2009-09-09 01:35:06.000000000 +0000 @@ -2139,6 +2143,9 @@ } - if (!in_nullhost(gsa->sin.sin_addr)) + if (!in_nullhost(gsa->sin.sin_addr)) { INADDR_TO_IFP(mreqs.imr_interface, ifp); + if (ifp == NULL) + return (EADDRNOTAVAIL); + } CTR3(KTR_IGMPV3, "%s: imr_interface = %s, ifp = %p", --------------040206040408060908060700-- From owner-freebsd-net@FreeBSD.ORG Wed Sep 9 11:40:28 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCF38106566B for ; Wed, 9 Sep 2009 11:40:28 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63902.mail.re1.yahoo.com (web63902.mail.re1.yahoo.com [69.147.97.117]) by mx1.freebsd.org (Postfix) with SMTP id 83D958FC13 for ; Wed, 9 Sep 2009 11:40:28 +0000 (UTC) Received: (qmail 15992 invoked by uid 60001); 9 Sep 2009 11:40:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1252496426; bh=Z+YrokIH7xSrQsGCDqcdkUjuJdzZ2ZA67gn4Am1jPOs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HUKvEyYBTxbOee94raB+/mJgj318E+PjHud6/TTqdKH5K30p1iVGT0a6pysRP44XnYv0H99v9JYhxPQjnvT9jxQKGzFPHo+afCxhoxR/20zvDZHvXfGTpLZqomnHIaFGs+jAiv3aFU/yZKDVgHHZiJJqJ+bPz5dibAOJORZYHyA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=PZQ6E7yAhlQfwS4tr0ztPPZeykPH8Dd6zwq11x2dtAB8N34mw+z0eoUWWJ1VOGLIgqDexxMSxNrDz+xk9VtbyoDk3izy4Qzx4dz95H85RmPqzZSawI1wY2oZqmD8QLiGUZwsaKY9M3FYjDu37oz4imOTHFjDLDhRqcewt0DhK2k=; Message-ID: <992693.15985.qm@web63902.mail.re1.yahoo.com> X-YMail-OSG: w6tsu50VM1mhCVVSn0W0kzit9VYQgy3qBVLvsROqM2O0KLwmO_fLCRg8gEusAIkx6KDv7muwoYHeYKbeKoVBRatDS8wLYcagCf0EzLV9ZpP1vAZ13rwgDSqvqij9svxAiJ0iA6_5hPiwN1yLEj8bs53IKrkAFtF3qRyuRlko5RZ.TIAIhpI2ZYYZJvGemDfIQ_vXdXkPfy_rA6uLMH79trqX4yuXUkfu9P4CXKukSJbyHOQNPkUXx13H.uwg48qLJET9PP4kFrsY9JjhA6EdHw_E71NnacwVTFcLVk9PycfzomvElr8p38WsHGl7BOkSvnBH5wmaVQ-- Received: from [98.203.21.152] by web63902.mail.re1.yahoo.com via HTTP; Wed, 09 Sep 2009 04:40:26 PDT X-Mailer: YahooMailClassic/6.1.2 YahooMailWebService/0.7.338.2 Date: Wed, 9 Sep 2009 04:40:26 -0700 (PDT) From: Barney Cordoba To: Mike Tancsa In-Reply-To: <200909082218.n88MI7TH073975@lava.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: em driver input errors X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 11:40:28 -0000 =0A=0A--- On Tue, 9/8/09, Mike Tancsa wrote:=0A=0A> From:= Mike Tancsa =0A> Subject: Re: em driver input errors=0A> = To: "Barney Cordoba" =0A> Cc: freebsd-net@freebsd= .org=0A> Date: Tuesday, September 8, 2009, 6:21 PM=0A> At 05:42 PM 9/8/2009= , Barney Cordoba=0A> wrote:=0A> > Manish What specific kinds of input error= s are you=0A> getting? How many PPS are you doing, what is the size of the= =0A> ring, and the interrupt modulation rate? Are the NICs PCIe=0A> or PCIx= ? Barney=0A> =0A> In my case, our backup server (mix of dump via nfs and so= me=0A> dumps through ssh as well as writes via samba mounts) has a=0A> fair= ly low pps rate and starts to see input errors at about=0A> 100Mb.=A0 Addin= g=0A> =0A> hw.em.rxd=3D4096=0A> hw.em.txd=3D4096=0A> =0A> and=0A> =0A> net.= inet.tcp.recvbuf_max=3D16777216=0A> net.inet.tcp.recvspace=3D131072=0A> net= .inet.tcp.sendbuf_max=3D16777216=0A> net.inet.tcp.sendspace=3D131072=0A> ne= t.inet.udp.recvspace=3D65536=0A> kern.ipc.somaxconn=3D1024=0A> kern.ipc.max= sockbuf=3D4194304=0A> net.inet.ip.redirect=3D0=0A> net.inet.ip.intr_queue_m= axlen=3D4096=0A> net.route.netisr_maxqlen=3D1024=0A> kern.ipc.nmbclusters= =3D655360=0A> =0A> didnt seem to make a difference in the amount of errors = I=0A> was seeing=0A> =0A> =0A> em1@pci0:7:5:0: class=3D0x020000 card=3D0x34= 8f8086=0A> chip=3D0x10768086 rev=3D0x05 hdr=3D0x00=0A> =A0 =A0 vendor=A0 = =A0=A0=A0=3D 'Intel=0A> Corporation'=0A> =A0 =A0 device=A0 =A0=A0=A0=3D 'Gi= gabit=0A> Ethernet Controller (82541EI)'=0A> =A0 =A0 class=A0 =A0 =A0 =3D n= etwork=0A> =A0 =A0 subclass=A0=A0=A0=3D ethernet=0A> =A0 =A0 cap 01[dc] =3D= powerspec 2=A0 supports D0=0A> D3=A0 current D0=0A> =A0 =A0 cap 07[e4] =3D= PCI-X supports 2048 burst read,=0A> 1 split transaction=0A> =0A> Core(TM)= 2 Quad CPU=A0 =A0 Q6600=A0 @ 2.40GHz,=0A> AMD64, RELENG_7 from Jun 18th=0A>= =0A> Plenty of disk IO left and the CPUs doent seem to be taxed=0A> that m= uch.=0A> =0A> Sep=A0 8 00:02:01 backup3 kernel: em1: Excessive=0A> collisio= ns =3D 0=0A> Sep=A0 8 00:02:01 backup3 kernel: em1: Sequence errors =3D=0A>= 0=0A> Sep=A0 8 00:02:01 backup3 kernel: em1: Defer count =3D 0=0A> Sep=A0 = 8 00:02:01 backup3 kernel: em1: Missed Packets =3D=0A> 61316=0A> Sep=A0 8 0= 0:02:01 backup3 kernel: em1: Receive No=0A> Buffers =3D 0=0A> Sep=A0 8 00:0= 2:01 backup3 kernel: em1: Receive Length=0A> Errors =3D 0=0A> Sep=A0 8 00:0= 2:01 backup3 kernel: em1: Receive errors =3D=0A> 0=0A> Sep=A0 8 00:02:01 ba= ckup3 kernel: em1: Crc errors =3D 0=0A> Sep=A0 8 00:02:01 backup3 kernel: e= m1: Alignment errors=0A> =3D 0=0A> Sep=A0 8 00:02:01 backup3 kernel: em1: C= ollision/Carrier=0A> extension errors =3D 0=0A> Sep=A0 8 00:02:01 backup3 k= ernel: em1: RX overruns =3D=0A> 22397=0A> Sep=A0 8 00:02:01 backup3 kernel:= em1: watchdog timeouts=0A> =3D 0=0A> Sep=A0 8 00:02:01 backup3 kernel: em1= : RX MSIX IRQ =3D 0=0A> TX MSIX IRQ =3D 0 LINK MSIX IRQ =3D 0=0A> Sep=A0 8 = 00:02:01 backup3 kernel: em1: XON Rcvd =3D 0=0A> Sep=A0 8 00:02:01 backup3 = kernel: em1: XON Xmtd =3D 0=0A> Sep=A0 8 00:02:01 backup3 kernel: em1: XOFF= Rcvd =3D 0=0A> Sep=A0 8 00:02:01 backup3 kernel: em1: XOFF Xmtd =3D 0=0A> = Sep=A0 8 00:02:01 backup3 kernel: em1: Good Packets Rcvd=0A> =3D 544276980= =0A> Sep=A0 8 00:02:01 backup3 kernel: em1: Good Packets Xmtd=0A> =3D 49047= 5071=0A> Sep=A0 8 00:02:01 backup3 kernel: em1: TSO Contexts Xmtd=0A> =3D 0= =0A> Sep=A0 8 00:02:01 backup3 kernel: em1: TSO Contexts=0A> Failed =3D 0= =0A> =0A> =0A> pf is in the kernel as well=0A> =0A> > _____________________= __________________________=0A> > freebsd-net@freebsd.org=0A> mailing list= =0A> > http://lists.freebsd.org/mailman/listinfo/freebsd-net=0A> > To unsub= scribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"=0A> =0A> ---= -----------------------------------------------------------------=0A> Mike = Tancsa,=A0 =A0 =A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> =A0 = =A0 =A0 =A0 =A0 tel +1 519 651 3400=0A> Sentex Communications,=A0 =A0 =A0 = =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> =A0 mike@sentex.net=0A> Pro= viding Internet since 1994=A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0 =A0 www.s= entex.net=0A> Cambridge, Ontario Canada=A0 =A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 = =A0 =A0 =A0=0A> =A0=A0=A0www.sentex.net/mike=0A> =0A> =0A=0AThe 8241GI may = not be able to handle full gigabit flows if its only=0Awired at 32-bit 33Mh= z, which is only capable of bursting to 1Gb/s. With=0Aa single NIC it likel= y just fine, but it a bridged or firewall type =0Aconfig you may just be se= eing bus failures.=0A=0ABarney=0A=0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Wed Sep 9 11:47:56 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AB211065670 for ; Wed, 9 Sep 2009 11:47:56 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63904.mail.re1.yahoo.com (web63904.mail.re1.yahoo.com [69.147.97.119]) by mx1.freebsd.org (Postfix) with SMTP id B94398FC0A for ; Wed, 9 Sep 2009 11:47:55 +0000 (UTC) Received: (qmail 15773 invoked by uid 60001); 9 Sep 2009 11:47:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1252496875; bh=CVic+M7IcSVR/7CcbGXT1uaCGQBAWIQMdZkQ81nujq0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0AyHCBU8onBvOHBU9g6vhE9jN238AzsnKLvjpDLk3yMvJpIc/XqSlaWxpnuV1P0wxQMUmRexhcD0eLGcLFWtfsOf7zGWac/AGXMrcBSkkkRhjy+Vpb7YMxhaYf4vhoo2/VmjMZwT2nq3mixCOIXPfA4BjBz2y0i/MJAuEIvqGMk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=CvO4Kw1HTBxpTwTNggQCPxipfiqoTh4+itXeZ4DSdeZB1l9q01rNMbJ3a4jjlvaMKEWyv5XqwNmld2+fyceoJE/JfYF4zzv83C27fXPicfhhLzRcq9a1wV9yVu90gbqyIegHbfWC/HMHE/6QZoVqXaqvcHFkGaNwmZ2QaLrN3Cw=; Message-ID: <62894.21638.qm@web63904.mail.re1.yahoo.com> X-YMail-OSG: Llpy_o4VM1mJCagkXToKos5aDMYPGqVcwfPxqUXM6MYDSW0IrBa.wUGbkXkjH5_KDCoKR310LCGvVax0RqF3bm8IsaQnE8mwiom6_FCchv8B1Uu7i3YqGCfpWbsxvfc0r8Fjs61d_.rxBY2hTTQXXWVveK.BP1IgzvnP85PgT6wJdGnyB8Cdm1Rhyxme_HVySX.rEZ7bqfmu2Amj4ersU15BURagdOIqHAu7ura_VA8KMoBHkLnJcnlopvKkcZjRItURGYvawnXNNcixVZuMfZ5WVQ50nKANHiRi05gAJ.iT6E0dN7GU9pfNn97DrS2juT1mOmaiEA-- Received: from [98.203.21.152] by web63904.mail.re1.yahoo.com via HTTP; Wed, 09 Sep 2009 04:47:55 PDT X-Mailer: YahooMailClassic/6.1.2 YahooMailWebService/0.7.338.2 Date: Wed, 9 Sep 2009 04:47:55 -0700 (PDT) From: Barney Cordoba To: Mike Tancsa In-Reply-To: <992693.15985.qm@web63902.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: em driver input errors X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 11:47:56 -0000 =0A=0A--- On Wed, 9/9/09, Barney Cordoba wrote:= =0A=0A> From: Barney Cordoba =0A> Subject: Re: em= driver input errors=0A> To: "Mike Tancsa" =0A> Cc: freebs= d-net@freebsd.org=0A> Date: Wednesday, September 9, 2009, 7:40 AM=0A> =0A> = =0A> --- On Tue, 9/8/09, Mike Tancsa =0A> wrote:=0A> =0A> = > From: Mike Tancsa =0A> > Subject: Re: em driver input er= rors=0A> > To: "Barney Cordoba" =0A> > Cc: freebs= d-net@freebsd.org=0A> > Date: Tuesday, September 8, 2009, 6:21 PM=0A> > At = 05:42 PM 9/8/2009, Barney Cordoba=0A> > wrote:=0A> > > Manish What specific= kinds of input errors are=0A> you=0A> > getting? How many PPS are you doin= g, what is the size=0A> of the=0A> > ring, and the interrupt modulation rat= e? Are the NICs=0A> PCIe=0A> > or PCIx? Barney=0A> > =0A> > In my case, our= backup server (mix of dump via nfs and=0A> some=0A> > dumps through ssh as= well as writes via samba mounts)=0A> has a=0A> > fairly low pps rate and s= tarts to see input errors at=0A> about=0A> > 100Mb.=A0 Adding=0A> > =0A> > = hw.em.rxd=3D4096=0A> > hw.em.txd=3D4096=0A> > =0A> > and=0A> > =0A> > net.i= net.tcp.recvbuf_max=3D16777216=0A> > net.inet.tcp.recvspace=3D131072=0A> > = net.inet.tcp.sendbuf_max=3D16777216=0A> > net.inet.tcp.sendspace=3D131072= =0A> > net.inet.udp.recvspace=3D65536=0A> > kern.ipc.somaxconn=3D1024=0A> >= kern.ipc.maxsockbuf=3D4194304=0A> > net.inet.ip.redirect=3D0=0A> > net.ine= t.ip.intr_queue_maxlen=3D4096=0A> > net.route.netisr_maxqlen=3D1024=0A> > k= ern.ipc.nmbclusters=3D655360=0A> > =0A> > didnt seem to make a difference i= n the amount of=0A> errors I=0A> > was seeing=0A> > =0A> > =0A> > em1@pci0:= 7:5:0: class=3D0x020000 card=3D0x348f8086=0A> > chip=3D0x10768086 rev=3D0x0= 5 hdr=3D0x00=0A> > =A0 =A0 vendor=A0 =A0=A0=A0=3D 'Intel=0A> > Corporation'= =0A> > =A0 =A0 device=A0 =A0=A0=A0=3D 'Gigabit=0A> > Ethernet Controller (8= 2541EI)'=0A> > =A0 =A0 class=A0 =A0 =A0 =3D network=0A> > =A0 =A0 subclass= =A0=A0=A0=3D ethernet=0A> > =A0 =A0 cap 01[dc] =3D powerspec 2=A0 supports = D0=0A> > D3=A0 current D0=0A> > =A0 =A0 cap 07[e4] =3D PCI-X supports 2048 = burst read,=0A> > 1 split transaction=0A> > =0A> >=A0 Core(TM)2 Quad CPU=A0= =A0 Q6600=A0 @ 2.40GHz,=0A> > AMD64, RELENG_7 from Jun 18th=0A> > =0A> > P= lenty of disk IO left and the CPUs doent seem to be=0A> taxed=0A> > that mu= ch.=0A> > =0A> > Sep=A0 8 00:02:01 backup3 kernel: em1: Excessive=0A> > col= lisions =3D 0=0A> > Sep=A0 8 00:02:01 backup3 kernel: em1: Sequence errors= =0A> =3D=0A> > 0=0A> > Sep=A0 8 00:02:01 backup3 kernel: em1: Defer count = =3D 0=0A> > Sep=A0 8 00:02:01 backup3 kernel: em1: Missed Packets=0A> =3D= =0A> > 61316=0A> > Sep=A0 8 00:02:01 backup3 kernel: em1: Receive No=0A> > = Buffers =3D 0=0A> > Sep=A0 8 00:02:01 backup3 kernel: em1: Receive Length= =0A> > Errors =3D 0=0A> > Sep=A0 8 00:02:01 backup3 kernel: em1: Receive er= rors=0A> =3D=0A> > 0=0A> > Sep=A0 8 00:02:01 backup3 kernel: em1: Crc error= s =3D 0=0A> > Sep=A0 8 00:02:01 backup3 kernel: em1: Alignment=0A> errors= =0A> > =3D 0=0A> > Sep=A0 8 00:02:01 backup3 kernel: em1:=0A> Collision/Car= rier=0A> > extension errors =3D 0=0A> > Sep=A0 8 00:02:01 backup3 kernel: e= m1: RX overruns =3D=0A> > 22397=0A> > Sep=A0 8 00:02:01 backup3 kernel: em1= : watchdog=0A> timeouts=0A> > =3D 0=0A> > Sep=A0 8 00:02:01 backup3 kernel:= em1: RX MSIX IRQ =3D 0=0A> > TX MSIX IRQ =3D 0 LINK MSIX IRQ =3D 0=0A> > S= ep=A0 8 00:02:01 backup3 kernel: em1: XON Rcvd =3D 0=0A> > Sep=A0 8 00:02:0= 1 backup3 kernel: em1: XON Xmtd =3D 0=0A> > Sep=A0 8 00:02:01 backup3 kerne= l: em1: XOFF Rcvd =3D 0=0A> > Sep=A0 8 00:02:01 backup3 kernel: em1: XOFF X= mtd =3D 0=0A> > Sep=A0 8 00:02:01 backup3 kernel: em1: Good Packets=0A> Rcv= d=0A> > =3D 544276980=0A> > Sep=A0 8 00:02:01 backup3 kernel: em1: Good Pac= kets=0A> Xmtd=0A> > =3D 490475071=0A> > Sep=A0 8 00:02:01 backup3 kernel: e= m1: TSO Contexts=0A> Xmtd=0A> > =3D 0=0A> > Sep=A0 8 00:02:01 backup3 kerne= l: em1: TSO Contexts=0A> > Failed =3D 0=0A> > =0A> > =0A> > pf is in the ke= rnel as well=0A> > =0A> > > _______________________________________________= =0A> > > freebsd-net@freebsd.org=0A> > mailing list=0A> > > http://lists.fr= eebsd.org/mailman/listinfo/freebsd-net=0A> > > To unsubscribe, send any mai= l to "freebsd-net-unsubscribe@freebsd.org"=0A> > =0A> >=0A> ---------------= -----------------------------------------------------=0A> > Mike Tancsa,=A0= =A0 =A0 =A0 =A0 =A0=0A> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> > =A0 =A0 = =A0 =A0 =A0 tel +1 519 651 3400=0A> > Sentex Communications,=A0 =A0 =A0 =A0= =A0=0A> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> > =A0 mike@sentex.net=0A> > = Providing Internet since 1994=A0 =A0 =A0 =A0=0A> > =A0 =A0 =A0 =A0 =A0 =A0 = www.sentex.net=0A> > Cambridge, Ontario Canada=A0 =A0 =A0 =A0 =A0=0A> > =A0= =A0 =A0 =A0 =A0 =A0=0A> > =A0=A0=A0www.sentex.net/mike=0A> > =0A> > =0A> = =0A> The 8241GI may not be able to handle full gigabit flows if=0A> its onl= y=0A> wired at 32-bit 33Mhz, which is only capable of bursting to=0A> 1Gb/s= . With=0A> a single NIC it likely just fine, but it a bridged or=0A> firewa= ll type =0A> config you may just be seeing bus failures.=0A> =0A> Barney=0A= =0AI meant 82541EI...Same answer.=0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Wed Sep 9 13:20:02 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 470A01065670 for ; Wed, 9 Sep 2009 13:20:02 +0000 (UTC) (envelope-from nevtic@area51.capnet.state.tx.us) Received: from area51.capnet.state.tx.us (area51.capnet.state.tx.us [141.198.193.51]) by mx1.freebsd.org (Postfix) with ESMTP id 9EE688FC13 for ; Wed, 9 Sep 2009 13:20:01 +0000 (UTC) Received: from area51.capnet.state.tx.us (localhost [127.0.0.1]) by area51.capnet.state.tx.us (8.14.3/8.14.3) with ESMTP id n89DKFn6009074 for ; Wed, 9 Sep 2009 08:20:15 -0500 (CDT) (envelope-from nevtic@area51.capnet.state.tx.us) Received: from localhost (nevtic@localhost) by area51.capnet.state.tx.us (8.14.3/8.14.3/Submit) with ESMTP id n89DKFQw009071 for ; Wed, 9 Sep 2009 08:20:15 -0500 (CDT) (envelope-from nevtic@area51.capnet.state.tx.us) Date: Tue, 8 Sep 2009 11:32:03 -0500 (CDT) From: stuart cur To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="657637799-1648946924-1252426673=:98111" Content-ID: ReSent-Date: Wed, 9 Sep 2009 08:18:49 -0500 (CDT) ReSent-From: stuart cur ReSent-To: freebsd-net@freebsd.org ReSent-Subject: 8.0-B4, Broadcom bge0 not working, HP Proliant DL385, amd64 ReSent-Message-ID: ReSent-User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cc: Subject: 8.0-B4, Broadcom bge0 not working, HP Proliant DL385, amd64 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 13:20:02 -0000 --657637799-1648946924-1252426673=:98111 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Content-ID: In 8.0-B4 for amd64, bge does not recognize that there is an active ethernet connection on bge0. Switching the cable to bge1 works correctly. This seems to be the same issue as reported on July 21 by Oyvind Rakvag, but I saw no response to that report. Attached are the dmesg.boot, /var/log/messages, and output of pciconf -lv from the very first boot. stu --657637799-1648946924-1252426673=:98111 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=messages Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME=messages U2VwICA4IDE1OjUxOjE3ICBuZXdzeXNsb2dbNzc1XTogbG9nZmlsZSBmaXJz dCBjcmVhdGVkDQpTZXAgIDggMTU6NTE6MTcgIHN5c2xvZ2Q6IGtlcm5lbCBi b290IGZpbGUgaXMgL2Jvb3Qva2VybmVsL2tlcm5lbA0KU2VwICA4IDE1OjUx OjE3ICBrZXJuZWw6IENvcHlyaWdodCAoYykgMTk5Mi0yMDA5IFRoZSBGcmVl QlNEIFByb2plY3QuDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogQ29weXJp Z2h0IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAx OTkxLCAxOTkyLCAxOTkzLCAxOTk0DQpTZXAgIDggMTU6NTE6MTcgIGtlcm5l bDogVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5p YS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4NClNlcCAgOCAxNTo1MToxNyAga2Vy bmVsOiBGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhl IEZyZWVCU0QgRm91bmRhdGlvbi4NClNlcCAgOCAxNTo1MToxNyAga2VybmVs OiBGcmVlQlNEIDguMC1CRVRBNCAjMDogU3VuIFNlcCAgNiAwNDo0NDozMSBV VEMgMjAwOQ0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IHJvb3RAbWFzb24u Y3NlLmJ1ZmZhbG8uZWR1Oi91c3Ivb2JqL3Vzci9zcmMvc3lzL0dFTkVSSUMN ClNlcCAgOCAxNTo1MToxNyAga2VybmVsOiBXQVJOSU5HOiBXSVRORVNTIG9w dGlvbiBlbmFibGVkLCBleHBlY3QgcmVkdWNlZCBwZXJmb3JtYW5jZS4NClNl cCAgOCAxNTo1MToxNyAga2VybmVsOiBUaW1lY291bnRlciAiaTgyNTQiIGZy ZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMA0KU2VwICA4IDE1OjUxOjE3 ICBrZXJuZWw6IENQVTogQU1EIE9wdGVyb24odG0pIFByb2Nlc3NvciAyNzAg KDIwMDQuNTUtTUh6IEs4LWNsYXNzIENQVSkNClNlcCAgOCAxNTo1MToxNyAg a2VybmVsOiBPcmlnaW4gPSAiQXV0aGVudGljQU1EIiAgSWQgPSAweDIwZjEy ICBTdGVwcGluZyA9IDINClNlcCAgOCAxNTo1MToxNyAga2VybmVsOiBGZWF0 dXJlcz0weDE3OGJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1D RSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENM RkxVU0gsTU1YLEZYU1IsU1NFLFNTRTIsSFRUPg0KU2VwICA4IDE1OjUxOjE3 ICBrZXJuZWw6IEZlYXR1cmVzMj0weDE8U1NFMz4NClNlcCAgOCAxNTo1MTox NyAga2VybmVsOiBBTUQgRmVhdHVyZXM9MHhlMjUwMDgwMDxTWVNDQUxMLE5Y LE1NWCssRkZYU1IsTE0sM0ROb3chKywzRE5vdyE+DQpTZXAgIDggMTU6NTE6 MTcgIGtlcm5lbDogQU1EIEZlYXR1cmVzMj0weDI8Q01QPg0KU2VwICA4IDE1 OjUxOjE3ICBrZXJuZWw6IHJlYWwgbWVtb3J5ICA9IDIxNDc0ODM2NDggKDIw NDggTUIpDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogYXZhaWwgbWVtb3J5 ID0gMjA1NDQwNjE0NCAoMTk1OSBNQikNClNlcCAgOCAxNTo1MToxNyAga2Vy bmVsOiBBQ1BJIEFQSUMgVGFibGU6IDxIUCAgICAgMDAwMDAwODM+DQpTZXAg IDggMTU6NTE6MTcgIGtlcm5lbDogRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vz c29yIFN5c3RlbSBEZXRlY3RlZDogMiBDUFVzDQpTZXAgIDggMTU6NTE6MTcg IGtlcm5lbDogRnJlZUJTRC9TTVA6IDEgcGFja2FnZShzKSB4IDIgY29yZShz KQ0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IGNwdTAgKEJTUCk6IEFQSUMg SUQ6ICAwDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogY3B1MSAoQVApOiBB UElDIElEOiAgMQ0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IEFDUEkgV2Fy bmluZzogSW52YWxpZCBsZW5ndGggZm9yIFBtMWFDb250cm9sQmxvY2s6IDMy LCB1c2luZyBkZWZhdWx0IDE2IDIwMDkwNTIxIHRiZmFkdC03MDcNClNlcCAg OCAxNTo1MToxNyAga2VybmVsOiBBQ1BJIFdhcm5pbmc6IEludmFsaWQgbGVu Z3RoIGZvciBQbTFiQ29udHJvbEJsb2NrOiAzMiwgdXNpbmcgZGVmYXVsdCAx NiAyMDA5MDUyMSB0YmZhZHQtNzA3DQpTZXAgIDggMTU6NTE6MTcgIGtlcm5l bDogTUFEVDogRm9yY2luZyBhY3RpdmUtbG93IHBvbGFyaXR5IGFuZCBsZXZl bCB0cmlnZ2VyIGZvciBTQ0kNClNlcCAgOCAxNTo1MToxNyAga2VybmVsOiBp b2FwaWMwIDxWZXJzaW9uIDEuMT4gaXJxcyAwLTIzIG9uIG1vdGhlcmJvYXJk DQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogaW9hcGljMSA8VmVyc2lvbiAx LjE+IGlycXMgMjQtMjcgb24gbW90aGVyYm9hcmQNClNlcCAgOCAxNTo1MTox NyAga2VybmVsOiBpb2FwaWMyIDxWZXJzaW9uIDEuMT4gaXJxcyAyOC0zMSBv biBtb3RoZXJib2FyZA0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IGlvYXBp YzMgPFZlcnNpb24gMS4xPiBpcnFzIDMyLTM1IG9uIG1vdGhlcmJvYXJkDQpT ZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogaW9hcGljNCA8VmVyc2lvbiAxLjE+ IGlycXMgMzYtMzkgb24gbW90aGVyYm9hcmQNClNlcCAgOCAxNTo1MToxNyAg a2VybmVsOiBrYmQxIGF0IGtiZG11eDANClNlcCAgOCAxNTo1MToxNyAga2Vy bmVsOiBhY3BpMDogPEhQIEEwNT4gb24gbW90aGVyYm9hcmQNClNlcCAgOCAx NTo1MToxNyAga2VybmVsOiBhY3BpMDogW0lUSFJFQURdDQpTZXAgIDggMTU6 NTE6MTcgIGtlcm5lbDogYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpDQpT ZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogVGltZWNvdW50ZXIgIkFDUEktc2Fm ZSIgZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSA4NTANClNlcCAgOCAx NTo1MToxNyAga2VybmVsOiBhY3BpX3RpbWVyMDogPDMyLWJpdCB0aW1lciBh dCAzLjU3OTU0NU1Iej4gcG9ydCAweDkwOC0weDkwYiBvbiBhY3BpMA0KU2Vw ICA4IDE1OjUxOjE3ICBrZXJuZWw6IHBjaWIwOiA8QUNQSSBIb3N0LVBDSSBi cmlkZ2U+IG9uIGFjcGkwDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogcGNp MDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjANClNlcCAgOCAxNTo1MToxNyAg a2VybmVsOiBwY2liMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmlj ZSAzLjAgb24gcGNpMA0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IHBjaTE6 IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxDQpTZXAgIDggMTU6NTE6MTcgIGtl cm5lbDogb2hjaTA6IDxPSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4g bWVtIDB4ZjdjZjAwMDAtMHhmN2NmMGZmZiBpcnEgMTkgYXQgZGV2aWNlIDAu MCBvbiBwY2kxDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogb2hjaTA6IFtJ VEhSRUFEXQ0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IHVzYnVzMDogPE9I Q0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBvbiBvaGNpMA0KU2VwICA4 IDE1OjUxOjE3ICBrZXJuZWw6IG9oY2kxOiA8T0hDSSAoZ2VuZXJpYykgVVNC IGNvbnRyb2xsZXI+IG1lbSAweGY3Y2UwMDAwLTB4ZjdjZTBmZmYgaXJxIDE5 IGF0IGRldmljZSAwLjEgb24gcGNpMQ0KU2VwICA4IDE1OjUxOjE3ICBrZXJu ZWw6IG9oY2kxOiBbSVRIUkVBRF0NClNlcCAgOCAxNTo1MToxNyAga2VybmVs OiB1c2J1czE6IDxPSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gb24g b2hjaTENClNlcCAgOCAxNTo1MToxNyAga2VybmVsOiBwY2kxOiA8YmFzZSBw ZXJpcGhlcmFsPiBhdCBkZXZpY2UgMi4wIChubyBkcml2ZXIgYXR0YWNoZWQp DQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogcGNpMTogPGJhc2UgcGVyaXBo ZXJhbD4gYXQgZGV2aWNlIDIuMiAobm8gZHJpdmVyIGF0dGFjaGVkKQ0KU2Vw ICA4IDE1OjUxOjE3ICBrZXJuZWw6IHZnYXBjaTA6IDxWR0EtY29tcGF0aWJs ZSBkaXNwbGF5PiBwb3J0IDB4NDQwMC0weDQ0ZmYgbWVtIDB4ZjYwMDAwMDAt MHhmNmZmZmZmZiwweGY1ZmYwMDAwLTB4ZjVmZjBmZmYgYXQgZGV2aWNlIDMu MCBvbiBwY2kxDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogaXNhYjA6IDxQ Q0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDQuMCBvbiBwY2kwDQpTZXAgIDgg MTU6NTE6MTcgIGtlcm5lbDogaXNhMDogPElTQSBidXM+IG9uIGlzYWIwDQpT ZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogYXRhcGNpMDogPEFNRCA4MTExIFVE TUExMzMgY29udHJvbGxlcj4gcG9ydCAweDFmMC0weDFmNywweDNmNiwweDE3 MC0weDE3NywweDM3NiwweDIwMDAtMHgyMDBmIGF0IGRldmljZSA0LjEgb24g cGNpMA0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IGF0YTA6IDxBVEEgY2hh bm5lbCAwPiBvbiBhdGFwY2kwDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDog YXRhMDogW0lUSFJFQURdDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogYXRh MTogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTANClNlcCAgOCAxNTo1MTox NyAga2VybmVsOiBhdGExOiBbSVRIUkVBRF0NClNlcCAgOCAxNTo1MToxNyAg a2VybmVsOiBwY2kwOiA8YnJpZGdlPiBhdCBkZXZpY2UgNC4zIChubyBkcml2 ZXIgYXR0YWNoZWQpDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogcGNpYjI6 IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgNy4wIG9uIHBjaTAN ClNlcCAgOCAxNTo1MToxNyAga2VybmVsOiBwY2kyOiA8QUNQSSBQQ0kgYnVz PiBvbiBwY2liMg0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IGNpc3MwOiA8 SFAgU21hcnQgQXJyYXkgNmk+IHBvcnQgMHg1MDAwLTB4NTBmZiBtZW0gMHhm N2RmMDAwMC0weGY3ZGYxZmZmLDB4ZjdkODAwMDAtMHhmN2RiZmZmZiBpcnEg MjQgYXQgZGV2aWNlIDQuMCBvbiBwY2kyDQpTZXAgIDggMTU6NTE6MTcgIGtl cm5lbDogY2lzczA6IFBFUkZPUk1BTlQgVHJhbnNwb3J0DQpTZXAgIDggMTU6 NTE6MTcgIGtlcm5lbDogY2lzczA6IFtJVEhSRUFEXQ0KU2VwICA4IDE1OjUx OjE3ICBrZXJuZWw6IHBjaWIzOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQg ZGV2aWNlIDguMCBvbiBwY2kwDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDog cGNpMzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjMNClNlcCAgOCAxNTo1MTox NyAga2VybmVsOiBiZ2UwOiA8SFAgTkM3NzgyIEdpZ2FiaXQgU2VydmVyIEFk YXB0ZXIsIEFTSUMgcmV2LiAweDIxMDA+IG1lbSAweGY3ZWYwMDAwLTB4Zjdl ZmZmZmYgaXJxIDI4IGF0IGRldmljZSA2LjAgb24gcGNpMw0KU2VwICA4IDE1 OjUxOjE3ICBrZXJuZWw6IG1paWJ1czA6IDxNSUkgYnVzPiBvbiBiZ2UwDQpT ZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogYnJncGh5MDogPEJDTTU3MDQgMTAv MTAwLzEwMDBiYXNlVFggUEhZPiBQSFkgMSBvbiBtaWlidXMwDQpTZXAgIDgg MTU6NTE6MTcgIGtlcm5lbDogYnJncGh5MDogIDEwYmFzZVQsIDEwYmFzZVQt RkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEwMDBiYXNlVCwgMTAw MGJhc2VULUZEWCwgYXV0bw0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IGJn ZTA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjE3OmE0OmE3OmViOmU0DQpTZXAg IDggMTU6NTE6MTcgIGtlcm5lbDogYmdlMDogW0lUSFJFQURdDQpTZXAgIDgg MTU6NTE6MTcgIGtlcm5lbDogYmdlMTogPEhQIE5DNzc4MiBHaWdhYml0IFNl cnZlciBBZGFwdGVyLCBBU0lDIHJldi4gMHgyMTAwPiBtZW0gMHhmN2VlMDAw MC0weGY3ZWVmZmZmIGlycSAyOSBhdCBkZXZpY2UgNi4xIG9uIHBjaTMNClNl cCAgOCAxNTo1MToxNyAga2VybmVsOiBtaWlidXMxOiA8TUlJIGJ1cz4gb24g YmdlMQ0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IGJyZ3BoeTE6IDxCQ001 NzA0IDEwLzEwMC8xMDAwYmFzZVRYIFBIWT4gUEhZIDEgb24gbWlpYnVzMQ0K U2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IGJyZ3BoeTE6ICAxMGJhc2VULCAx MGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDAwYmFz ZVQsIDEwMDBiYXNlVC1GRFgsIGF1dG8NClNlcCAgOCAxNTo1MToxNyAga2Vy bmVsOiBiZ2UxOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoxNzphNDphNzplYjpl Mw0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IGJnZTE6IFtJVEhSRUFEXQ0K U2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IHBjaWI0OiA8QUNQSSBIb3N0LVBD SSBicmlkZ2U+IG9uIGFjcGkwDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDog cGNpNDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjQNClNlcCAgOCAxNTo1MTox NyAga2VybmVsOiBwY2liNTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRl dmljZSA5LjAgb24gcGNpNA0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IHBj aTU6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI1DQpTZXAgIDggMTU6NTE6MTcg IGtlcm5lbDogcmwwOiA8UmVhbFRlayA4MTM5IDEwLzEwMEJhc2VUWD4gcG9y dCAweDYwMDAtMHg2MGZmIG1lbSAweGY3ZmYwMDAwLTB4ZjdmZjAwZmYgaXJx IDMyIGF0IGRldmljZSA4LjAgb24gcGNpNQ0KU2VwICA4IDE1OjUxOjE3ICBr ZXJuZWw6IG1paWJ1czI6IDxNSUkgYnVzPiBvbiBybDANClNlcCAgOCAxNTo1 MToxNyAga2VybmVsOiBybHBoeTA6IDxSZWFsVGVrIGludGVybmFsIG1lZGlh IGludGVyZmFjZT4gUEhZIDAgb24gbWlpYnVzMg0KU2VwICA4IDE1OjUxOjE3 ICBrZXJuZWw6IHJscGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBi YXNlVFgsIDEwMGJhc2VUWC1GRFgsIGF1dG8NClNlcCAgOCAxNTo1MToxNyAg a2VybmVsOiBybDA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjQwOmY0OmVkOjk5 OmVjDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogcmwwOiBbSVRIUkVBRF0N ClNlcCAgOCAxNTo1MToxNyAga2VybmVsOiBwY2liNjogPEFDUEkgUENJLVBD SSBicmlkZ2U+IGF0IGRldmljZSAxMC4wIG9uIHBjaTQNClNlcCAgOCAxNTo1 MToxNyAga2VybmVsOiBwY2k2OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNg0K U2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IGF0a2JkYzA6IDxLZXlib2FyZCBj b250cm9sbGVyIChpODA0Mik+IHBvcnQgMHg2MCwweDY0IGlycSAxIG9uIGFj cGkwDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogYXRrYmQwOiA8QVQgS2V5 Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzANClNlcCAgOCAxNTo1MToxNyAga2Vy bmVsOiBrYmQwIGF0IGF0a2JkMA0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6 IGF0a2JkMDogW0dJQU5ULUxPQ0tFRF0NClNlcCAgOCAxNTo1MToxNyAga2Vy bmVsOiBhdGtiZDA6IFtJVEhSRUFEXQ0KU2VwICA4IDE1OjUxOjE3ICBrZXJu ZWw6IHBzbTA6IDxQUy8yIE1vdXNlPiBpcnEgMTIgb24gYXRrYmRjMA0KU2Vw ICA4IDE1OjUxOjE3ICBrZXJuZWw6IHBzbTA6IFtHSUFOVC1MT0NLRURdDQpT ZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogcHNtMDogW0lUSFJFQURdDQpTZXAg IDggMTU6NTE6MTcgIGtlcm5lbDogcHNtMDogbW9kZWwgR2VuZXJpYyBQUy8y IG1vdXNlLCBkZXZpY2UgSUQgMA0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6 IHVhcnQwOiA8MTY1NTAgb3IgY29tcGF0aWJsZT4gcG9ydCAweDNmOC0weDNm ZiBpcnEgNCBmbGFncyAweDEwIG9uIGFjcGkwDQpTZXAgIDggMTU6NTE6MTcg IGtlcm5lbDogdWFydDA6IFtGSUxURVJdDQpTZXAgIDggMTU6NTE6MTcgIGtl cm5lbDogZmRjMDogPGZsb3BweSBkcml2ZSBjb250cm9sbGVyIChGREUpPiBw b3J0IDB4M2YyLTB4M2Y1IGlycSA2IGRycSAyIG9uIGFjcGkwDQpTZXAgIDgg MTU6NTE6MTcgIGtlcm5lbDogZmRjMDogW0ZJTFRFUl0NClNlcCAgOCAxNTo1 MToxNyAga2VybmVsOiBjcHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkwDQpTZXAg IDggMTU6NTE6MTcgIGtlcm5lbDogcG93ZXJub3cwOiA8Q29vbGBuJ1F1aWV0 IEs4PiBvbiBjcHUwDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogY3B1MTog PEFDUEkgQ1BVPiBvbiBhY3BpMA0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6 IHBvd2Vybm93MTogPENvb2xgbidRdWlldCBLOD4gb24gY3B1MQ0KU2VwICA4 IDE1OjUxOjE3ICBrZXJuZWw6IG9ybTA6IDxJU0EgT3B0aW9uIFJPTXM+IGF0 IGlvbWVtIDB4YzAwMDAtMHhjN2ZmZiwweGM4MDAwLTB4Y2JmZmYsMHhlZTAw MC0weGVmZmZmIG9uIGlzYTANClNlcCAgOCAxNTo1MToxNyAga2VybmVsOiBz YzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMA0K U2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IHNjMDogVkdBIDwxNiB2aXJ0dWFs IGNvbnNvbGVzLCBmbGFncz0weDMwMD4NClNlcCAgOCAxNTo1MToxNyAga2Vy bmVsOiB2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4 M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwDQpTZXAgIDggMTU6 NTE6MTcgIGtlcm5lbDogYXRydGMwOiA8QVQgUmVhbCBUaW1lIENsb2NrPiBh dCBwb3J0IDB4NzAgaXJxIDggb24gaXNhMA0KU2VwICA4IDE1OjUxOjE3ICBr ZXJuZWw6IHBwYzA6IGNhbm5vdCByZXNlcnZlIEkvTyBwb3J0IHJhbmdlDQpT ZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogdWFydDE6IDxOb24tc3RhbmRhcmQg bnM4MjUwIGNsYXNzIFVBUlQgd2l0aCBGSUZPcz4gYXQgcG9ydCAweDJmOC0w eDJmZiBpcnEgMyBvbiBpc2EwDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDog dWFydDE6IFtGSUxURVJdDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogVGlt ZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYw0KU2VwICA4IDE1OjUx OjE3ICBrZXJuZWw6IHVzYnVzMDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYx LjANClNlcCAgOCAxNTo1MToxNyAga2VybmVsOiB1c2J1czE6IDEyTWJwcyBG dWxsIFNwZWVkIFVTQiB2MS4wDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDog dWdlbjAuMTogPEFNRD4gYXQgdXNidXMwDQpTZXAgIDggMTU6NTE6MTcgIGtl cm5lbDogdWh1YjA6IDxBTUQgT0hDSSByb290IEhVQiwgY2xhc3MgOS8wLCBy ZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMA0KU2VwICA4IDE1OjUx OjE3ICBrZXJuZWw6IHVnZW4xLjE6IDxBTUQ+IGF0IHVzYnVzMQ0KU2VwICA4 IDE1OjUxOjE3ICBrZXJuZWw6IHVodWIxOiA8QU1EIE9IQ0kgcm9vdCBIVUIs IGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czEN ClNlcCAgOCAxNTo1MToxNyAga2VybmVsOiBhY2QwOiBDRFJXIDxEVy0yMjRF LVIvQy5BQj4gYXQgYXRhMC1tYXN0ZXIgVURNQTMzDQpTZXAgIDggMTU6NTE6 MTcgIGtlcm5lbDogdWh1YjA6IDMgcG9ydHMgd2l0aCAzIHJlbW92YWJsZSwg c2VsZiBwb3dlcmVkDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogdWh1YjE6 IDMgcG9ydHMgd2l0aCAzIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQpTZXAg IDggMTU6NTE6MTcgIGtlcm5lbDogZGEwIGF0IGNpc3MwIGJ1cyAwIHRhcmdl dCAwIGx1biAwDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogZGEwOiA8Q09N UEFRIFJBSUQgMSAgVk9MVU1FIE9LPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFND U0ktNCBkZXZpY2UgDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogZGEwOiAx MzUuMTY4TUIvcyB0cmFuc2ZlcnMNClNlcCAgOCAxNTo1MToxNyAga2VybmVs OiBkYTA6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZA0KU2VwICA4IDE1OjUx OjE3ICBrZXJuZWw6IGRhMDogNzAwMDFNQiAoMTQzMzYzMDQwIDUxMiBieXRl IHNlY3RvcnM6IDI1NUggMzJTL1QgMTc1NjlDKQ0KU2VwICA4IDE1OjUxOjE3 ICBrZXJuZWw6IGRhMSBhdCBjaXNzMCBidXMgMCB0YXJnZXQgMSBsdW4gMA0K U2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IGRhMTogPENPTVBBUSBSQUlEIDEg IFZPTFVNRSBPSz4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTQgZGV2aWNl IA0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IGRhMTogMTM1LjE2OE1CL3Mg dHJhbnNmZXJzDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogZGExOiBDb21t YW5kIFF1ZXVlaW5nIGVuYWJsZWQNClNlcCAgOCAxNTo1MToxNyAga2VybmVs OiBkYTE6IDI4NjA5N01CICg1ODU5MjgyMjAgNTEyIGJ5dGUgc2VjdG9yczog MjU1SCAzMlMvVCA2NTUzNUMpDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDog U01QOiBBUCBDUFUgIzEgTGF1bmNoZWQhDQpTZXAgIDggMTU6NTE6MTcgIGtl cm5lbDogV0FSTklORzogV0lUTkVTUyBvcHRpb24gZW5hYmxlZCwgZXhwZWN0 IHJlZHVjZWQgcGVyZm9ybWFuY2UuDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5l bDogR0VPTTogZGEwOiBwYXJ0aXRpb24gMSBkb2VzIG5vdCBzdGFydCBvbiBh IHRyYWNrIGJvdW5kYXJ5Lg0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IEdF T006IGRhMDogcGFydGl0aW9uIDEgZG9lcyBub3QgZW5kIG9uIGEgdHJhY2sg Ym91bmRhcnkuDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogR0VPTTogZGEw czE6IGdlb21ldHJ5IGRvZXMgbm90IG1hdGNoIGxhYmVsICgyNTVoLDYzcyAh PSAyNTVoLDMycykuDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogR0VPTTog ZGExOiBwYXJ0aXRpb24gMSBkb2VzIG5vdCBzdGFydCBvbiBhIHRyYWNrIGJv dW5kYXJ5Lg0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IEdFT006IGRhMTog cGFydGl0aW9uIDEgZG9lcyBub3QgZW5kIG9uIGEgdHJhY2sgYm91bmRhcnku DQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogR0VPTTogZGExczE6IGdlb21l dHJ5IGRvZXMgbm90IG1hdGNoIGxhYmVsICgyNTVoLDYzcyAhPSAyNTVoLDMy cykuDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogVHJ5aW5nIHRvIG1vdW50 IHJvb3QgZnJvbSB1ZnM6L2Rldi9kYTBzMWENClNlcCAgOCAxNTo1MToyOCAg bG9naW46IFJPT1QgTE9HSU4gKHJvb3QpIE9OIHR0eXYxDQpTZXAgIDggMTU6 NTI6MTIgIGtlcm5lbDogYmdlMTogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQ DQpTZXAgIDggMTU6NTI6NTEgIGtlcm5lbDogYmdlMTogbGluayBzdGF0ZSBj aGFuZ2VkIHRvIERPV04NClNlcCAgOCAxNTo1Mjo1MyAga2VybmVsOiBiZ2Ux OiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVANClNlcCAgOCAxNTo1Mzo0OSAg a2VybmVsOiBiZ2UxOiBwcm9taXNjdW91cyBtb2RlIGVuYWJsZWQNClNlcCAg OCAxNTo1NDoxMiAga2VybmVsOiBiZ2UxOiBwcm9taXNjdW91cyBtb2RlIGRp c2FibGVkDQpTZXAgIDggMTU6NTk6MTkgIHJvb3Q6IFVua25vd24gVVNCIGRl dmljZTogdmVuZG9yIDB4MTNmZSBwcm9kdWN0IDB4MWEyMSBidXMgdWh1YjEN ClNlcCAgOCAxNTo1OToxOSAga2VybmVsOiB1Z2VuMS4yOiA8dmVuZG9yIDB4 MTNmZT4gYXQgdXNidXMxDQpTZXAgIDggMTU6NTk6MTkgIGtlcm5lbDogdW1h c3MwOiA8dmVuZG9yIDB4MTNmZSBVU0IgRElTSyBQcm8sIGNsYXNzIDAvMCwg cmV2IDIuMDAvMS4wMCwgYWRkciAyPiBvbiB1c2J1czENClNlcCAgOCAxNTo1 OToxOSAga2VybmVsOiB1bWFzczA6ICBTQ1NJIG92ZXIgQnVsay1Pbmx5OyBx dWlya3MgPSAweDAwMDANClNlcCAgOCAxNTo1OToyMCAga2VybmVsOiB1bWFz czA6MzowOi0xOiBBdHRhY2hlZCB0byBzY2J1czMNClNlcCAgOCAxNTo1OToy MSAga2VybmVsOiAocHJvYmUwOnVtYXNzLXNpbTA6MDowOjApOiBURVNUIFVO SVQgUkVBRFkuIENEQjogMCAwIDAgMCAwIDAgDQpTZXAgIDggMTU6NTk6MjEg IGtlcm5lbDogKHByb2JlMDp1bWFzcy1zaW0wOjA6MDowKTogQ0FNIFN0YXR1 czogU0NTSSBTdGF0dXMgRXJyb3INClNlcCAgOCAxNTo1OToyMSAga2VybmVs OiAocHJvYmUwOnVtYXNzLXNpbTA6MDowOjApOiBTQ1NJIFN0YXR1czogQ2hl Y2sgQ29uZGl0aW9uDQpTZXAgIDggMTU6NTk6MjEgIGtlcm5lbDogKHByb2Jl MDp1bWFzcy1zaW0wOjA6MDowKTogVU5JVCBBVFRFTlRJT04gYXNjOjI4LDAN ClNlcCAgOCAxNTo1OToyMSAga2VybmVsOiAocHJvYmUwOnVtYXNzLXNpbTA6 MDowOjApOiBOb3QgcmVhZHkgdG8gcmVhZHkgY2hhbmdlLCBtZWRpdW0gbWF5 IGhhdmUgY2hhbmdlZA0KU2VwICA4IDE1OjU5OjIxICBrZXJuZWw6IChwcm9i ZTA6dW1hc3Mtc2ltMDowOjA6MCk6IFJldHJ5aW5nIENvbW1hbmQgKHBlciBT ZW5zZSBEYXRhKQ0KU2VwICA4IDE1OjU5OjIxICBrZXJuZWw6IGRhMiBhdCB1 bWFzcy1zaW0wIGJ1cyAwIHRhcmdldCAwIGx1biAwDQpTZXAgIDggMTU6NTk6 MjEgIGtlcm5lbDogZGEyOiA8IFVTQiBESVNLIFBybyBQTUFQPiBSZW1vdmFi bGUgRGlyZWN0IEFjY2VzcyBTQ1NJLTAgZGV2aWNlIA0KU2VwICA4IDE1OjU5 OjIxICBrZXJuZWw6IGRhMjogMS4wMDBNQi9zIHRyYW5zZmVycw0KU2VwICA4 IDE1OjU5OjIxICBrZXJuZWw6IGRhMjogMTk0MU1CICgzOTc2MTkyIDUxMiBi eXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgMjQ3QykNClNlcCAgOCAxNTo1OToy MSAga2VybmVsOiAocHJvYmUwOnVtYXNzLXNpbTA6MDowOjEpOiBURVNUIFVO SVQgUkVBRFkuIENEQjogMCAyMCAwIDAgMCAwIA0KU2VwICA4IDE1OjU5OjIx ICBrZXJuZWw6IChwcm9iZTA6dW1hc3Mtc2ltMDowOjA6MSk6IENBTSBTdGF0 dXM6IFNDU0kgU3RhdHVzIEVycm9yDQpTZXAgIDggMTU6NTk6MjEgIGtlcm5l bDogKHByb2JlMDp1bWFzcy1zaW0wOjA6MDoxKTogU0NTSSBTdGF0dXM6IENo ZWNrIENvbmRpdGlvbg0KU2VwICA4IDE1OjU5OjIxICBrZXJuZWw6IChwcm9i ZTA6dW1hc3Mtc2ltMDowOjA6MSk6IFVOSVQgQVRURU5USU9OIGFzYzoyOCww DQpTZXAgIDggMTU6NTk6MjEgIGtlcm5lbDogKHByb2JlMDp1bWFzcy1zaW0w OjA6MDoxKTogTm90IHJlYWR5IHRvIHJlYWR5IGNoYW5nZSwgbWVkaXVtIG1h eSBoYXZlIGNoYW5nZWQNClNlcCAgOCAxNTo1OToyMSAga2VybmVsOiAocHJv YmUwOnVtYXNzLXNpbTA6MDowOjEpOiBSZXRyeWluZyBDb21tYW5kIChwZXIg U2Vuc2UgRGF0YSkNClNlcCAgOCAxNTo1OToyMSAga2VybmVsOiBkYTMgYXQg dW1hc3Mtc2ltMCBidXMgMCB0YXJnZXQgMCBsdW4gMQ0KU2VwICA4IDE1OjU5 OjIxICBrZXJuZWw6IGRhMzogPCBVU0IgRElTSyBQcm8gUE1BUD4gUmVtb3Zh YmxlIERpcmVjdCBBY2Nlc3MgU0NTSS0wIGRldmljZSANClNlcCAgOCAxNTo1 OToyMSAga2VybmVsOiBkYTM6IDEuMDAwTUIvcyB0cmFuc2ZlcnMNClNlcCAg OCAxNTo1OToyMSAga2VybmVsOiBkYTM6IDI0TUIgKDUwMTc2IDUxMiBieXRl IHNlY3RvcnM6IDY0SCAzMlMvVCAyNEMpDQpTZXAgIDggMTU6NTk6MjIgIGtl cm5lbDogR0VPTTogZGEyOiBwYXJ0aXRpb24gMSBkb2VzIG5vdCBzdGFydCBv biBhIHRyYWNrIGJvdW5kYXJ5Lg0KU2VwICA4IDE1OjU5OjIyICBrZXJuZWw6 IEdFT006IGRhMjogcGFydGl0aW9uIDEgZG9lcyBub3QgZW5kIG9uIGEgdHJh Y2sgYm91bmRhcnkuDQo= --657637799-1648946924-1252426673=:98111 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=dmesg.boot Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME=dmesg.boot Q29weXJpZ2h0IChjKSAxOTkyLTIwMDkgVGhlIEZyZWVCU0QgUHJvamVjdC4N CkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwg MTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0KCVRoZSBSZWdlbnRzIG9m IHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVz ZXJ2ZWQuDQpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2Yg VGhlIEZyZWVCU0QgRm91bmRhdGlvbi4NCkZyZWVCU0QgOC4wLUJFVEE0ICMw OiBTdW4gU2VwICA2IDA0OjQ0OjMxIFVUQyAyMDA5DQogICAgcm9vdEBtYXNv bi5jc2UuYnVmZmFsby5lZHU6L3Vzci9vYmovdXNyL3NyYy9zeXMvR0VORVJJ Qw0KV0FSTklORzogV0lUTkVTUyBvcHRpb24gZW5hYmxlZCwgZXhwZWN0IHJl ZHVjZWQgcGVyZm9ybWFuY2UuDQpUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1 ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMA0KQ1BVOiBBTUQgT3B0ZXJvbih0 bSkgUHJvY2Vzc29yIDI3MCAoMjAwNC41NS1NSHogSzgtY2xhc3MgQ1BVKQ0K ICBPcmlnaW4gPSAiQXV0aGVudGljQU1EIiAgSWQgPSAweDIwZjEyICBTdGVw cGluZyA9IDINCiAgRmVhdHVyZXM9MHgxNzhiZmJmZjxGUFUsVk1FLERFLFBT RSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxD TU9WLFBBVCxQU0UzNixDTEZMVVNILE1NWCxGWFNSLFNTRSxTU0UyLEhUVD4N CiAgRmVhdHVyZXMyPTB4MTxTU0UzPg0KICBBTUQgRmVhdHVyZXM9MHhlMjUw MDgwMDxTWVNDQUxMLE5YLE1NWCssRkZYU1IsTE0sM0ROb3chKywzRE5vdyE+ DQogIEFNRCBGZWF0dXJlczI9MHgyPENNUD4NCnJlYWwgbWVtb3J5ICA9IDIx NDc0ODM2NDggKDIwNDggTUIpDQphdmFpbCBtZW1vcnkgPSAyMDU0NDA2MTQ0 ICgxOTU5IE1CKQ0KQUNQSSBBUElDIFRhYmxlOiA8SFAgICAgIDAwMDAwMDgz Pg0KRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3RlbSBEZXRlY3Rl ZDogMiBDUFVzDQpGcmVlQlNEL1NNUDogMSBwYWNrYWdlKHMpIHggMiBjb3Jl KHMpDQogY3B1MCAoQlNQKTogQVBJQyBJRDogIDANCiBjcHUxIChBUCk6IEFQ SUMgSUQ6ICAxDQpBQ1BJIFdhcm5pbmc6IEludmFsaWQgbGVuZ3RoIGZvciBQ bTFhQ29udHJvbEJsb2NrOiAzMiwgdXNpbmcgZGVmYXVsdCAxNiAyMDA5MDUy MSB0YmZhZHQtNzA3DQpBQ1BJIFdhcm5pbmc6IEludmFsaWQgbGVuZ3RoIGZv ciBQbTFiQ29udHJvbEJsb2NrOiAzMiwgdXNpbmcgZGVmYXVsdCAxNiAyMDA5 MDUyMSB0YmZhZHQtNzA3DQpNQURUOiBGb3JjaW5nIGFjdGl2ZS1sb3cgcG9s YXJpdHkgYW5kIGxldmVsIHRyaWdnZXIgZm9yIFNDSQ0KaW9hcGljMCA8VmVy c2lvbiAxLjE+IGlycXMgMC0yMyBvbiBtb3RoZXJib2FyZA0KaW9hcGljMSA8 VmVyc2lvbiAxLjE+IGlycXMgMjQtMjcgb24gbW90aGVyYm9hcmQNCmlvYXBp YzIgPFZlcnNpb24gMS4xPiBpcnFzIDI4LTMxIG9uIG1vdGhlcmJvYXJkDQpp b2FwaWMzIDxWZXJzaW9uIDEuMT4gaXJxcyAzMi0zNSBvbiBtb3RoZXJib2Fy ZA0KaW9hcGljNCA8VmVyc2lvbiAxLjE+IGlycXMgMzYtMzkgb24gbW90aGVy Ym9hcmQNCmtiZDEgYXQga2JkbXV4MA0KYWNwaTA6IDxIUCBBMDU+IG9uIG1v dGhlcmJvYXJkDQphY3BpMDogW0lUSFJFQURdDQphY3BpMDogUG93ZXIgQnV0 dG9uIChmaXhlZCkNClRpbWVjb3VudGVyICJBQ1BJLXNhZmUiIGZyZXF1ZW5j eSAzNTc5NTQ1IEh6IHF1YWxpdHkgODUwDQphY3BpX3RpbWVyMDogPDMyLWJp dCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDkwOC0weDkwYiBvbiBh Y3BpMA0KcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gb24gYWNwaTAN CnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwDQpwY2liMTogPEFDUEkg UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAzLjAgb24gcGNpMA0KcGNpMTog PEFDUEkgUENJIGJ1cz4gb24gcGNpYjENCm9oY2kwOiA8T0hDSSAoZ2VuZXJp YykgVVNCIGNvbnRyb2xsZXI+IG1lbSAweGY3Y2YwMDAwLTB4ZjdjZjBmZmYg aXJxIDE5IGF0IGRldmljZSAwLjAgb24gcGNpMQ0Kb2hjaTA6IFtJVEhSRUFE XQ0KdXNidXMwOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9u IG9oY2kwDQpvaGNpMTogPE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVy PiBtZW0gMHhmN2NlMDAwMC0weGY3Y2UwZmZmIGlycSAxOSBhdCBkZXZpY2Ug MC4xIG9uIHBjaTENCm9oY2kxOiBbSVRIUkVBRF0NCnVzYnVzMTogPE9IQ0kg KGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBvbiBvaGNpMQ0KcGNpMTogPGJh c2UgcGVyaXBoZXJhbD4gYXQgZGV2aWNlIDIuMCAobm8gZHJpdmVyIGF0dGFj aGVkKQ0KcGNpMTogPGJhc2UgcGVyaXBoZXJhbD4gYXQgZGV2aWNlIDIuMiAo bm8gZHJpdmVyIGF0dGFjaGVkKQ0KdmdhcGNpMDogPFZHQS1jb21wYXRpYmxl IGRpc3BsYXk+IHBvcnQgMHg0NDAwLTB4NDRmZiBtZW0gMHhmNjAwMDAwMC0w eGY2ZmZmZmZmLDB4ZjVmZjAwMDAtMHhmNWZmMGZmZiBhdCBkZXZpY2UgMy4w IG9uIHBjaTENCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSA0 LjAgb24gcGNpMA0KaXNhMDogPElTQSBidXM+IG9uIGlzYWIwDQphdGFwY2kw OiA8QU1EIDgxMTEgVURNQTEzMyBjb250cm9sbGVyPiBwb3J0IDB4MWYwLTB4 MWY3LDB4M2Y2LDB4MTcwLTB4MTc3LDB4Mzc2LDB4MjAwMC0weDIwMGYgYXQg ZGV2aWNlIDQuMSBvbiBwY2kwDQphdGEwOiA8QVRBIGNoYW5uZWwgMD4gb24g YXRhcGNpMA0KYXRhMDogW0lUSFJFQURdDQphdGExOiA8QVRBIGNoYW5uZWwg MT4gb24gYXRhcGNpMA0KYXRhMTogW0lUSFJFQURdDQpwY2kwOiA8YnJpZGdl PiBhdCBkZXZpY2UgNC4zIChubyBkcml2ZXIgYXR0YWNoZWQpDQpwY2liMjog PEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSA3LjAgb24gcGNpMA0K cGNpMjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjINCmNpc3MwOiA8SFAgU21h cnQgQXJyYXkgNmk+IHBvcnQgMHg1MDAwLTB4NTBmZiBtZW0gMHhmN2RmMDAw MC0weGY3ZGYxZmZmLDB4ZjdkODAwMDAtMHhmN2RiZmZmZiBpcnEgMjQgYXQg ZGV2aWNlIDQuMCBvbiBwY2kyDQpjaXNzMDogUEVSRk9STUFOVCBUcmFuc3Bv cnQNCmNpc3MwOiBbSVRIUkVBRF0NCnBjaWIzOiA8QUNQSSBQQ0ktUENJIGJy aWRnZT4gYXQgZGV2aWNlIDguMCBvbiBwY2kwDQpwY2kzOiA8QUNQSSBQQ0kg YnVzPiBvbiBwY2liMw0KYmdlMDogPEhQIE5DNzc4MiBHaWdhYml0IFNlcnZl ciBBZGFwdGVyLCBBU0lDIHJldi4gMHgyMTAwPiBtZW0gMHhmN2VmMDAwMC0w eGY3ZWZmZmZmIGlycSAyOCBhdCBkZXZpY2UgNi4wIG9uIHBjaTMNCm1paWJ1 czA6IDxNSUkgYnVzPiBvbiBiZ2UwDQpicmdwaHkwOiA8QkNNNTcwNCAxMC8x MDAvMTAwMGJhc2VUWCBQSFk+IFBIWSAxIG9uIG1paWJ1czANCmJyZ3BoeTA6 ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgt RkRYLCAxMDAwYmFzZVQsIDEwMDBiYXNlVC1GRFgsIGF1dG8NCmJnZTA6IEV0 aGVybmV0IGFkZHJlc3M6IDAwOjE3OmE0OmE3OmViOmU0DQpiZ2UwOiBbSVRI UkVBRF0NCmJnZTE6IDxIUCBOQzc3ODIgR2lnYWJpdCBTZXJ2ZXIgQWRhcHRl ciwgQVNJQyByZXYuIDB4MjEwMD4gbWVtIDB4ZjdlZTAwMDAtMHhmN2VlZmZm ZiBpcnEgMjkgYXQgZGV2aWNlIDYuMSBvbiBwY2kzDQptaWlidXMxOiA8TUlJ IGJ1cz4gb24gYmdlMQ0KYnJncGh5MTogPEJDTTU3MDQgMTAvMTAwLzEwMDBi YXNlVFggUEhZPiBQSFkgMSBvbiBtaWlidXMxDQpicmdwaHkxOiAgMTBiYXNl VCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgMTAw MGJhc2VULCAxMDAwYmFzZVQtRkRYLCBhdXRvDQpiZ2UxOiBFdGhlcm5ldCBh ZGRyZXNzOiAwMDoxNzphNDphNzplYjplMw0KYmdlMTogW0lUSFJFQURdDQpw Y2liNDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBvbiBhY3BpMA0KcGNpNDog PEFDUEkgUENJIGJ1cz4gb24gcGNpYjQNCnBjaWI1OiA8QUNQSSBQQ0ktUENJ IGJyaWRnZT4gYXQgZGV2aWNlIDkuMCBvbiBwY2k0DQpwY2k1OiA8QUNQSSBQ Q0kgYnVzPiBvbiBwY2liNQ0KcmwwOiA8UmVhbFRlayA4MTM5IDEwLzEwMEJh c2VUWD4gcG9ydCAweDYwMDAtMHg2MGZmIG1lbSAweGY3ZmYwMDAwLTB4Zjdm ZjAwZmYgaXJxIDMyIGF0IGRldmljZSA4LjAgb24gcGNpNQ0KbWlpYnVzMjog PE1JSSBidXM+IG9uIHJsMA0KcmxwaHkwOiA8UmVhbFRlayBpbnRlcm5hbCBt ZWRpYSBpbnRlcmZhY2U+IFBIWSAwIG9uIG1paWJ1czINCnJscGh5MDogIDEw YmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgs IGF1dG8NCnJsMDogRXRoZXJuZXQgYWRkcmVzczogMDA6NDA6ZjQ6ZWQ6OTk6 ZWMNCnJsMDogW0lUSFJFQURdDQpwY2liNjogPEFDUEkgUENJLVBDSSBicmlk Z2U+IGF0IGRldmljZSAxMC4wIG9uIHBjaTQNCnBjaTY6IDxBQ1BJIFBDSSBi dXM+IG9uIHBjaWI2DQphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAo aTgwNDIpPiBwb3J0IDB4NjAsMHg2NCBpcnEgMSBvbiBhY3BpMA0KYXRrYmQw OiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzANCmtiZDAgYXQgYXRr YmQwDQphdGtiZDA6IFtHSUFOVC1MT0NLRURdDQphdGtiZDA6IFtJVEhSRUFE XQ0KcHNtMDogPFBTLzIgTW91c2U+IGlycSAxMiBvbiBhdGtiZGMwDQpwc20w OiBbR0lBTlQtTE9DS0VEXQ0KcHNtMDogW0lUSFJFQURdDQpwc20wOiBtb2Rl bCBHZW5lcmljIFBTLzIgbW91c2UsIGRldmljZSBJRCAwDQp1YXJ0MDogPDE2 NTUwIG9yIGNvbXBhdGlibGU+IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQgZmxh Z3MgMHgxMCBvbiBhY3BpMA0KdWFydDA6IFtGSUxURVJdDQpmZGMwOiA8Zmxv cHB5IGRyaXZlIGNvbnRyb2xsZXIgKEZERSk+IHBvcnQgMHgzZjItMHgzZjUg aXJxIDYgZHJxIDIgb24gYWNwaTANCmZkYzA6IFtGSUxURVJdDQpjcHUwOiA8 QUNQSSBDUFU+IG9uIGFjcGkwDQpwb3dlcm5vdzA6IDxDb29sYG4nUXVpZXQg Szg+IG9uIGNwdTANCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNwaTANCnBvd2Vy bm93MTogPENvb2xgbidRdWlldCBLOD4gb24gY3B1MQ0Kb3JtMDogPElTQSBP cHRpb24gUk9Ncz4gYXQgaW9tZW0gMHhjMDAwMC0weGM3ZmZmLDB4YzgwMDAt MHhjYmZmZiwweGVlMDAwLTB4ZWZmZmYgb24gaXNhMA0Kc2MwOiA8U3lzdGVt IGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTANCnNjMDogVkdBIDwx NiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4NCnZnYTA6IDxHZW5l cmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAw MC0weGJmZmZmIG9uIGlzYTANCmF0cnRjMDogPEFUIFJlYWwgVGltZSBDbG9j az4gYXQgcG9ydCAweDcwIGlycSA4IG9uIGlzYTANCnBwYzA6IGNhbm5vdCBy ZXNlcnZlIEkvTyBwb3J0IHJhbmdlDQp1YXJ0MTogPE5vbi1zdGFuZGFyZCBu czgyNTAgY2xhc3MgVUFSVCB3aXRoIEZJRk9zPiBhdCBwb3J0IDB4MmY4LTB4 MmZmIGlycSAzIG9uIGlzYTANCnVhcnQxOiBbRklMVEVSXQ0KVGltZWNvdW50 ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYw0KdXNidXMwOiAxMk1icHMgRnVs bCBTcGVlZCBVU0IgdjEuMA0KdXNidXMxOiAxMk1icHMgRnVsbCBTcGVlZCBV U0IgdjEuMA0KdWdlbjAuMTogPEFNRD4gYXQgdXNidXMwDQp1aHViMDogPEFN RCBPSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFk ZHIgMT4gb24gdXNidXMwDQp1Z2VuMS4xOiA8QU1EPiBhdCB1c2J1czENCnVo dWIxOiA8QU1EIE9IQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAv MS4wMCwgYWRkciAxPiBvbiB1c2J1czENCmFjZDA6IENEUlcgPERXLTIyNEUt Ui9DLkFCPiBhdCBhdGEwLW1hc3RlciBVRE1BMzMNCnVodWIwOiAzIHBvcnRz IHdpdGggMyByZW1vdmFibGUsIHNlbGYgcG93ZXJlZA0KdWh1YjE6IDMgcG9y dHMgd2l0aCAzIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQpkYTAgYXQgY2lz czAgYnVzIDAgdGFyZ2V0IDAgbHVuIDANCmRhMDogPENPTVBBUSBSQUlEIDEg IFZPTFVNRSBPSz4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTQgZGV2aWNl IA0KZGEwOiAxMzUuMTY4TUIvcyB0cmFuc2ZlcnMNCmRhMDogQ29tbWFuZCBR dWV1ZWluZyBlbmFibGVkDQpkYTA6IDcwMDAxTUIgKDE0MzM2MzA0MCA1MTIg Ynl0ZSBzZWN0b3JzOiAyNTVIIDMyUy9UIDE3NTY5QykNCmRhMSBhdCBjaXNz MCBidXMgMCB0YXJnZXQgMSBsdW4gMA0KZGExOiA8Q09NUEFRIFJBSUQgMSAg Vk9MVU1FIE9LPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktNCBkZXZpY2Ug DQpkYTE6IDEzNS4xNjhNQi9zIHRyYW5zZmVycw0KZGExOiBDb21tYW5kIFF1 ZXVlaW5nIGVuYWJsZWQNCmRhMTogMjg2MDk3TUIgKDU4NTkyODIyMCA1MTIg Ynl0ZSBzZWN0b3JzOiAyNTVIIDMyUy9UIDY1NTM1QykNClNNUDogQVAgQ1BV ICMxIExhdW5jaGVkIQ0KV0FSTklORzogV0lUTkVTUyBvcHRpb24gZW5hYmxl ZCwgZXhwZWN0IHJlZHVjZWQgcGVyZm9ybWFuY2UuDQpHRU9NOiBkYTA6IHBh cnRpdGlvbiAxIGRvZXMgbm90IHN0YXJ0IG9uIGEgdHJhY2sgYm91bmRhcnku DQpHRU9NOiBkYTA6IHBhcnRpdGlvbiAxIGRvZXMgbm90IGVuZCBvbiBhIHRy YWNrIGJvdW5kYXJ5Lg0KR0VPTTogZGEwczE6IGdlb21ldHJ5IGRvZXMgbm90 IG1hdGNoIGxhYmVsICgyNTVoLDYzcyAhPSAyNTVoLDMycykuDQpHRU9NOiBk YTE6IHBhcnRpdGlvbiAxIGRvZXMgbm90IHN0YXJ0IG9uIGEgdHJhY2sgYm91 bmRhcnkuDQpHRU9NOiBkYTE6IHBhcnRpdGlvbiAxIGRvZXMgbm90IGVuZCBv biBhIHRyYWNrIGJvdW5kYXJ5Lg0KR0VPTTogZGExczE6IGdlb21ldHJ5IGRv ZXMgbm90IG1hdGNoIGxhYmVsICgyNTVoLDYzcyAhPSAyNTVoLDMycykuDQpU cnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L2RhMHMxYQ0K --657637799-1648946924-1252426673=:98111 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=pciconf-lv Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=pciconf-lv cGNpYjFAcGNpMDowOjM6MDoJY2xhc3M9MHgwNjA0MDAgY2FyZD0weDAwMDAw MDAwIGNoaXA9MHg3NDYwMTAyMiByZXY9MHgwNyBoZHI9MHgwMQ0KICAgIHZl bmRvciAgICAgPSAnQWR2YW5jZWQgTWljcm8gRGV2aWNlcyAoQU1EKScNCiAg ICBkZXZpY2UgICAgID0gJ1BDSSBCcmlkZ2UgKEFNRC04MTExKScNCiAgICBj bGFzcyAgICAgID0gYnJpZGdlDQogICAgc3ViY2xhc3MgICA9IFBDSS1QQ0kN CmlzYWIwQHBjaTA6MDo0OjA6CWNsYXNzPTB4MDYwMTAwIGNhcmQ9MHgzMjAz MGUxMSBjaGlwPTB4NzQ2ODEwMjIgcmV2PTB4MDUgaGRyPTB4MDANCiAgICB2 ZW5kb3IgICAgID0gJ0FkdmFuY2VkIE1pY3JvIERldmljZXMgKEFNRCknDQog ICAgZGV2aWNlICAgICA9ICdMUEMgQnJpZGdlIChBTUQtODExMSknDQogICAg Y2xhc3MgICAgICA9IGJyaWRnZQ0KICAgIHN1YmNsYXNzICAgPSBQQ0ktSVNB DQphdGFwY2kwQHBjaTA6MDo0OjE6CWNsYXNzPTB4MDEwMThhIGNhcmQ9MHgz MjA0MGUxMSBjaGlwPTB4NzQ2OTEwMjIgcmV2PTB4MDMgaGRyPTB4MDANCiAg ICB2ZW5kb3IgICAgID0gJ0FkdmFuY2VkIE1pY3JvIERldmljZXMgKEFNRCkn DQogICAgZGV2aWNlICAgICA9ICdVbHRyYUFUQS8xMzMgQ29udHJvbGxlciAo QU1ELTgxMTEpJw0KICAgIGNsYXNzICAgICAgPSBtYXNzIHN0b3JhZ2UNCiAg ICBzdWJjbGFzcyAgID0gQVRBDQpub25lMEBwY2kwOjA6NDozOgljbGFzcz0w eDA2ODAwMCBjYXJkPTB4MzIwNTBlMTEgY2hpcD0weDc0NmIxMDIyIHJldj0w eDA1IGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBZHZhbmNlZCBNaWNy byBEZXZpY2VzIChBTUQpJw0KICAgIGRldmljZSAgICAgPSAnQU1ELTgxMTEg QUNQSSBTeXN0ZW0gTWFuYWdlbWVudCBDb250cm9sbGVyJw0KICAgIGNsYXNz ICAgICAgPSBicmlkZ2UNCnBjaWIyQHBjaTA6MDo3OjA6CWNsYXNzPTB4MDYw NDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4NzQ1MDEwMjIgcmV2PTB4MTIg aGRyPTB4MDENCiAgICB2ZW5kb3IgICAgID0gJ0FkdmFuY2VkIE1pY3JvIERl dmljZXMgKEFNRCknDQogICAgZGV2aWNlICAgICA9ICdQQ0ktWCBCcmlkZ2Ug KEFNRC04MTMxKScNCiAgICBjbGFzcyAgICAgID0gYnJpZGdlDQogICAgc3Vi Y2xhc3MgICA9IFBDSS1QQ0kNCmlvYXBpYzBAcGNpMDowOjc6MToJY2xhc3M9 MHgwODAwMTAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHg3NDUxMTAyMiByZXY9 MHgwMSBoZHI9MHgwMA0KICAgIHZlbmRvciAgICAgPSAnQWR2YW5jZWQgTWlj cm8gRGV2aWNlcyAoQU1EKScNCiAgICBkZXZpY2UgICAgID0gJ1BDSS1YIElP QVBJQyAoQU1ELTgxMzEpJw0KICAgIGNsYXNzICAgICAgPSBiYXNlIHBlcmlw aGVyYWwNCiAgICBzdWJjbGFzcyAgID0gaW50ZXJydXB0IGNvbnRyb2xsZXIN CnBjaWIzQHBjaTA6MDo4OjA6CWNsYXNzPTB4MDYwNDAwIGNhcmQ9MHgwMDAw MDAwMCBjaGlwPTB4NzQ1MDEwMjIgcmV2PTB4MTIgaGRyPTB4MDENCiAgICB2 ZW5kb3IgICAgID0gJ0FkdmFuY2VkIE1pY3JvIERldmljZXMgKEFNRCknDQog ICAgZGV2aWNlICAgICA9ICdQQ0ktWCBCcmlkZ2UgKEFNRC04MTMxKScNCiAg ICBjbGFzcyAgICAgID0gYnJpZGdlDQogICAgc3ViY2xhc3MgICA9IFBDSS1Q Q0kNCmlvYXBpYzFAcGNpMDowOjg6MToJY2xhc3M9MHgwODAwMTAgY2FyZD0w eDAwMDAwMDAwIGNoaXA9MHg3NDUxMTAyMiByZXY9MHgwMSBoZHI9MHgwMA0K ICAgIHZlbmRvciAgICAgPSAnQWR2YW5jZWQgTWljcm8gRGV2aWNlcyAoQU1E KScNCiAgICBkZXZpY2UgICAgID0gJ1BDSS1YIElPQVBJQyAoQU1ELTgxMzEp Jw0KICAgIGNsYXNzICAgICAgPSBiYXNlIHBlcmlwaGVyYWwNCiAgICBzdWJj bGFzcyAgID0gaW50ZXJydXB0IGNvbnRyb2xsZXINCmhvc3RiMEBwY2kwOjA6 MjQ6MDoJY2xhc3M9MHgwNjAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgx MTAwMTAyMiByZXY9MHgwMCBoZHI9MHgwMA0KICAgIHZlbmRvciAgICAgPSAn QWR2YW5jZWQgTWljcm8gRGV2aWNlcyAoQU1EKScNCiAgICBkZXZpY2UgICAg ID0gJ0F0aGxvbjY0L09wdGVyb24vU2VtcHJvbiAoSzggRmFtaWx5KSBIeXBl clRyYW5zcG9ydCBUZWNobm9sb2d5IENvbmZpZ3VyYXRpb24nDQogICAgY2xh c3MgICAgICA9IGJyaWRnZQ0KICAgIHN1YmNsYXNzICAgPSBIT1NULVBDSQ0K aG9zdGIxQHBjaTA6MDoyNDoxOgljbGFzcz0weDA2MDAwMCBjYXJkPTB4MDAw MDAwMDAgY2hpcD0weDExMDExMDIyIHJldj0weDAwIGhkcj0weDAwDQogICAg dmVuZG9yICAgICA9ICdBZHZhbmNlZCBNaWNybyBEZXZpY2VzIChBTUQpJw0K ICAgIGRldmljZSAgICAgPSAnQXRobG9uNjQvT3B0ZXJvbi9TZW1wcm9uIChL OCBGYW1pbHkpIEFkZHJlc3MgTWFwJw0KICAgIGNsYXNzICAgICAgPSBicmlk Z2UNCiAgICBzdWJjbGFzcyAgID0gSE9TVC1QQ0kNCmhvc3RiMkBwY2kwOjA6 MjQ6MjoJY2xhc3M9MHgwNjAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgx MTAyMTAyMiByZXY9MHgwMCBoZHI9MHgwMA0KICAgIHZlbmRvciAgICAgPSAn QWR2YW5jZWQgTWljcm8gRGV2aWNlcyAoQU1EKScNCiAgICBkZXZpY2UgICAg ID0gJ0F0aGxvbjY0L09wdGVyb24vU2VtcHJvbiAoSzggRmFtaWx5KSBEUkFN IENvbnRyb2xsZXInDQogICAgY2xhc3MgICAgICA9IGJyaWRnZQ0KICAgIHN1 YmNsYXNzICAgPSBIT1NULVBDSQ0KaG9zdGIzQHBjaTA6MDoyNDozOgljbGFz cz0weDA2MDAwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDExMDMxMDIyIHJl dj0weDAwIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBZHZhbmNlZCBN aWNybyBEZXZpY2VzIChBTUQpJw0KICAgIGRldmljZSAgICAgPSAnQXRobG9u NjQvT3B0ZXJvbi9TZW1wcm9uIChLOCBGYW1pbHkpIE1pc2NlbGxhbmVvdXMg Q29udHJvbCcNCiAgICBjbGFzcyAgICAgID0gYnJpZGdlDQogICAgc3ViY2xh c3MgICA9IEhPU1QtUENJDQpvaGNpMEBwY2kwOjE6MDowOgljbGFzcz0weDBj MDMxMCBjYXJkPTB4MzIwMjBlMTEgY2hpcD0weDc0NjQxMDIyIHJldj0weDBi IGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBZHZhbmNlZCBNaWNybyBE ZXZpY2VzIChBTUQpJw0KICAgIGRldmljZSAgICAgPSAnVVNCIE9wZW5IQ0kg SG9zdCBDb250cm9sbGVyIChBTUQtODExMSknDQogICAgY2xhc3MgICAgICA9 IHNlcmlhbCBidXMNCiAgICBzdWJjbGFzcyAgID0gVVNCDQpvaGNpMUBwY2kw OjE6MDoxOgljbGFzcz0weDBjMDMxMCBjYXJkPTB4MzIwMjBlMTEgY2hpcD0w eDc0NjQxMDIyIHJldj0weDBiIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9 ICdBZHZhbmNlZCBNaWNybyBEZXZpY2VzIChBTUQpJw0KICAgIGRldmljZSAg ICAgPSAnVVNCIE9wZW5IQ0kgSG9zdCBDb250cm9sbGVyIChBTUQtODExMSkn DQogICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMNCiAgICBzdWJjbGFzcyAg ID0gVVNCDQpub25lMUBwY2kwOjE6MjowOgljbGFzcz0weDA4ODAwMCBjYXJk PTB4YjIwNjBlMTEgY2hpcD0weGIyMDMwZTExIHJldj0weDAxIGhkcj0weDAw DQogICAgdmVuZG9yICAgICA9ICdDb21wYXEgQ29tcHV0ZXIgQ29ycCAoTm93 IG93bmVkIGJ5IEhld2xldHQtUGFja2FyZCknDQogICAgZGV2aWNlICAgICA9 ICdJbnRlZ3JhdGVkIExpZ2h0cyBPdXQgUHJvY2Vzc29yIChpTG8pJw0KICAg IGNsYXNzICAgICAgPSBiYXNlIHBlcmlwaGVyYWwNCm5vbmUyQHBjaTA6MToy OjI6CWNsYXNzPTB4MDg4MDAwIGNhcmQ9MHhiMjA2MGUxMSBjaGlwPTB4YjIw NDBlMTEgcmV2PTB4MDEgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ0Nv bXBhcSBDb21wdXRlciBDb3JwIChOb3cgb3duZWQgYnkgSGV3bGV0dC1QYWNr YXJkKScNCiAgICBkZXZpY2UgICAgID0gJ0ludGVncmF0ZWQgTGlnaHRzIE91 dCBQcm9jZXNzb3IgKGlMbyknDQogICAgY2xhc3MgICAgICA9IGJhc2UgcGVy aXBoZXJhbA0KdmdhcGNpMEBwY2kwOjE6MzowOgljbGFzcz0weDAzMDAwMCBj YXJkPTB4MDAxZTBlMTEgY2hpcD0weDQ3NTIxMDAyIHJldj0weDI3IGhkcj0w eDAwDQogICAgdmVuZG9yICAgICA9ICdBVEkgVGVjaG5vbG9naWVzIEluYy4g LyBBZHZhbmNlZCBNaWNybyBEZXZpY2VzLCBJbmMuJw0KICAgIGRldmljZSAg ICAgPSAnQVRJIE9uLUJvYXJkIFZHQSBmb3IgSFAgUHJvbGlhbnQgMzUwIEcz IChSYWdlIFhMIFBDSSknDQogICAgY2xhc3MgICAgICA9IGRpc3BsYXkNCiAg ICBzdWJjbGFzcyAgID0gVkdBDQpjaXNzMEBwY2kwOjI6NDowOgljbGFzcz0w eDAxMDQwMCBjYXJkPTB4NDA5MTBlMTEgY2hpcD0weDAwNDYwZTExIHJldj0w eDAxIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdDb21wYXEgQ29tcHV0 ZXIgQ29ycCAoTm93IG93bmVkIGJ5IEhld2xldHQtUGFja2FyZCknDQogICAg ZGV2aWNlICAgICA9ICdTbWFydCBBcnJheSA2NHh4LzZpIENvbnRyb2xsZXIn DQogICAgY2xhc3MgICAgICA9IG1hc3Mgc3RvcmFnZQ0KICAgIHN1YmNsYXNz ICAgPSBSQUlEDQpiZ2UwQHBjaTA6Mzo2OjA6CWNsYXNzPTB4MDIwMDAwIGNh cmQ9MHgwMGQwMGUxMSBjaGlwPTB4MTY0ODE0ZTQgcmV2PTB4MTAgaGRyPTB4 MDANCiAgICB2ZW5kb3IgICAgID0gJ0Jyb2FkY29tIENvcnBvcmF0aW9uJw0K ICAgIGRldmljZSAgICAgPSAnTmV0WHRyZW1lIER1YWwgR2lnYWJpdCBBZGFw dGVyIChCQ001NzA0KScNCiAgICBjbGFzcyAgICAgID0gbmV0d29yaw0KICAg IHN1YmNsYXNzICAgPSBldGhlcm5ldA0KYmdlMUBwY2kwOjM6NjoxOgljbGFz cz0weDAyMDAwMCBjYXJkPTB4MDBkMDBlMTEgY2hpcD0weDE2NDgxNGU0IHJl dj0weDEwIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdCcm9hZGNvbSBD b3Jwb3JhdGlvbicNCiAgICBkZXZpY2UgICAgID0gJ05ldFh0cmVtZSBEdWFs IEdpZ2FiaXQgQWRhcHRlciAoQkNNNTcwNCknDQogICAgY2xhc3MgICAgICA9 IG5ldHdvcmsNCiAgICBzdWJjbGFzcyAgID0gZXRoZXJuZXQNCnBjaWI1QHBj aTA6NDo5OjA6CWNsYXNzPTB4MDYwNDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlw PTB4NzQ1MDEwMjIgcmV2PTB4MTIgaGRyPTB4MDENCiAgICB2ZW5kb3IgICAg ID0gJ0FkdmFuY2VkIE1pY3JvIERldmljZXMgKEFNRCknDQogICAgZGV2aWNl ICAgICA9ICdQQ0ktWCBCcmlkZ2UgKEFNRC04MTMxKScNCiAgICBjbGFzcyAg ICAgID0gYnJpZGdlDQogICAgc3ViY2xhc3MgICA9IFBDSS1QQ0kNCmlvYXBp YzJAcGNpMDo0Ojk6MToJY2xhc3M9MHgwODAwMTAgY2FyZD0weDAwMDAwMDAw IGNoaXA9MHg3NDUxMTAyMiByZXY9MHgwMSBoZHI9MHgwMA0KICAgIHZlbmRv ciAgICAgPSAnQWR2YW5jZWQgTWljcm8gRGV2aWNlcyAoQU1EKScNCiAgICBk ZXZpY2UgICAgID0gJ1BDSS1YIElPQVBJQyAoQU1ELTgxMzEpJw0KICAgIGNs YXNzICAgICAgPSBiYXNlIHBlcmlwaGVyYWwNCiAgICBzdWJjbGFzcyAgID0g aW50ZXJydXB0IGNvbnRyb2xsZXINCnBjaWI2QHBjaTA6NDoxMDowOgljbGFz cz0weDA2MDQwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDc0NTAxMDIyIHJl dj0weDEyIGhkcj0weDAxDQogICAgdmVuZG9yICAgICA9ICdBZHZhbmNlZCBN aWNybyBEZXZpY2VzIChBTUQpJw0KICAgIGRldmljZSAgICAgPSAnUENJLVgg QnJpZGdlIChBTUQtODEzMSknDQogICAgY2xhc3MgICAgICA9IGJyaWRnZQ0K ICAgIHN1YmNsYXNzICAgPSBQQ0ktUENJDQppb2FwaWMzQHBjaTA6NDoxMDox OgljbGFzcz0weDA4MDAxMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDc0NTEx MDIyIHJldj0weDAxIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBZHZh bmNlZCBNaWNybyBEZXZpY2VzIChBTUQpJw0KICAgIGRldmljZSAgICAgPSAn UENJLVggSU9BUElDIChBTUQtODEzMSknDQogICAgY2xhc3MgICAgICA9IGJh c2UgcGVyaXBoZXJhbA0KICAgIHN1YmNsYXNzICAgPSBpbnRlcnJ1cHQgY29u dHJvbGxlcg0KcmwwQHBjaTA6NTo4OjA6CWNsYXNzPTB4MDIwMDAwIGNhcmQ9 MHhjMTBmMTI1OSBjaGlwPTB4ODEzOTEwZWMgcmV2PTB4MTAgaGRyPTB4MDAN CiAgICB2ZW5kb3IgICAgID0gJ1JlYWx0ZWsgU2VtaWNvbmR1Y3RvcicNCiAg ICBkZXZpY2UgICAgID0gJ1JlYWx0ZWsgUlRMODEzOSBGYW1pbHkgUENJIEZh c3QgRXRoZXJuZXQgTklDIChSVEwtODEzOS84MTM5Qy84MTM5QyknDQogICAg Y2xhc3MgICAgICA9IG5ldHdvcmsNCiAgICBzdWJjbGFzcyAgID0gZXRoZXJu ZXQNCg== --657637799-1648946924-1252426673=:98111-- From owner-freebsd-net@FreeBSD.ORG Wed Sep 9 13:55:56 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F338E1065670 for ; Wed, 9 Sep 2009 13:55:56 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id C1DD18FC1D for ; Wed, 9 Sep 2009 13:55:56 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n89DqQDx079631; Wed, 9 Sep 2009 09:52:26 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200909091352.n89DqQDx079631@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 09 Sep 2009 09:55:52 -0400 To: Barney Cordoba From: Mike Tancsa In-Reply-To: <62894.21638.qm@web63904.mail.re1.yahoo.com> References: <992693.15985.qm@web63902.mail.re1.yahoo.com> <62894.21638.qm@web63904.mail.re1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: em driver input errors X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 13:55:57 -0000 At 07:47 AM 9/9/2009, Barney Cordoba wrote: > www.sentex.net/mike > > > > > > The 8241GI may not be able to > handle full gigabit flows if > its only > wired at 32-bit 33Mhz, > which is only capable of bursting to > 1Gb/s. With > a single NIC > it likely just fine, but it a bridged or > firewall type > config > you may just be seeing bus failures. > > Barney I meant > 82541EI...Same answer. Both of the NICs on this motherboard are wired in. I will see if there is a spare pcie slot and try a different em nic. Its also a single nic. No bridge or forwarding as all the packets are destined to the machine itself. ---Mike >_______________________________________________ >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" -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-net@FreeBSD.ORG Wed Sep 9 14:19:32 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C50B106566C for ; Wed, 9 Sep 2009 14:19:32 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63901.mail.re1.yahoo.com (web63901.mail.re1.yahoo.com [69.147.97.116]) by mx1.freebsd.org (Postfix) with SMTP id 490968FC13 for ; Wed, 9 Sep 2009 14:19:32 +0000 (UTC) Received: (qmail 7399 invoked by uid 60001); 9 Sep 2009 14:19:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1252505971; bh=s7W2J7AbUx8wCOxoVCdSOE3/iSnTvjeCB01UjqhuQBI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=59ncwNT8GjkpMCYE1DR7O09OvIrpFXjTgyC/FsYYQ9spCihdrrfzQyuoMyGIl/GLNUqZ2o4GFZL1hTFfIoTvBIq0LXokZt2fdpNSTp6FdS/TxNqkBwxFUaqrqD36ZLiahZLX7MiUNZ0Sv2cd86jXOJRlye4TgYikr5LuF1q2WQc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=eRzlI1oAXmRcENbOgFrAFmmX/FjQt05PQbeTDAczGn7Y3RPjEXOxCGbr2NoQbBM59KMH/S9oJckdfxBUbpCn8tGtluVihNoYtFMmUT9vdMEmKejd9WwNv1VshErYkld27PYU2FrOhq5Wbl44IuTo5LLZ81szPnZ6LKdSYF70iH4=; Message-ID: <538232.7388.qm@web63901.mail.re1.yahoo.com> X-YMail-OSG: 7tRhlWMVM1kvhnXIGcR7IPwwICjK7hHWlaB_sUg5EQ9HKNPvKaupOPf2R.dIngwSvqq847XXfBxnb094BxND4V5uStLgLexCAw3z_rfD86oKbxcISY4CT0LIKLBN9DQhCfOKmTkzBdwBol3h2pK5xmZA2EN6b_8bkm_IabSlTw1y_5IEEP2afAdJKvgh0Lgs0h9VeyWEtIpt5iLYYE2Fkn8Xynu29BjEVNeA.WYUnJ5RdVHUF.SjR0G4KjhIYeDHr5l7rUT3WGdvbeSzE_j9SDwC6gD4Mc4UePazo.ZLcoonIQ-- Received: from [98.203.21.152] by web63901.mail.re1.yahoo.com via HTTP; Wed, 09 Sep 2009 14:19:31 GMT X-Mailer: YahooMailClassic/6.1.2 YahooMailWebService/0.7.338.2 Date: Wed, 9 Sep 2009 14:19:31 +0000 (GMT) From: Barney Cordoba To: Mike Tancsa In-Reply-To: <200909091352.n89DqQDx079631@lava.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: em driver input errors X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 14:19:32 -0000 =0A=0A--- On Wed, 9/9/09, Mike Tancsa wrote:=0A=0A> From:= Mike Tancsa =0A> Subject: Re: em driver input errors=0A> = To: "Barney Cordoba" =0A> Cc: freebsd-net@freebsd= .org=0A> Date: Wednesday, September 9, 2009, 9:55 AM=0A> At 07:47 AM 9/9/20= 09, Barney Cordoba=0A> wrote:=0A> >=A0 =A0 www.sentex.net/mike > > > >=0A> = > > The 8241GI may not be able to handle full gigabit=0A> flows if > its on= ly > wired at 32-bit 33Mhz, which is=0A> only capable of bursting to > 1Gb/= s. With > a single=0A> NIC it likely just fine, but it a bridged or > firew= all=0A> type > config you may just be seeing bus failures. >=0A> > Barney I= meant 82541EI...Same answer.=0A> =0A> =0A> Both of the NICs on this mother= board are wired in.=A0 I=0A> will see if there is a spare pcie slot and try= a different=0A> em nic.=A0 Its also a single nic. No bridge or forwarding= =0A> as all the packets are destined to the machine itself.=0A> =0A> =A0 = =A0 =A0 =A0 ---Mike=0A> =0A> > ____________________________________________= ___=0A> > freebsd-net@freebsd.org=0A> mailing list=0A> > http://lists.freeb= sd.org/mailman/listinfo/freebsd-net=0A> > To unsubscribe, send any mail to = "freebsd-net-unsubscribe@freebsd.org"=0A> =0A> ----------------------------= ----------------------------------------=0A> Mike Tancsa,=A0 =A0 =A0 =A0 = =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0 tel +1 = 519 651 3400=0A> Sentex Communications,=A0 =A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0=0A> =A0 mike@sentex.net=0A> Providing Internet since 19= 94=A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0 =A0 www.sentex.net=0A> Cambridge,= Ontario Canada=A0 =A0 =A0 =A0 =A0=0A=0AA quick test would be to force it t= o 100Mb/s to see if the problem goes=0Aaway. I see you are using em1 which= implies another NIC...if you have=0Atraffic on the other lan its not much = different than=0A=0AAlso, realize that most pciX busses are shared. So your= disk and other=0Adevices may be sharing. Its really derilect for these MB = manufacturers=0Ato sell dual gig nic systems and them wire them to a slow b= us. But its=0Awhat they do.=0A=0ABarney=0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Wed Sep 9 14:29:02 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2721B1065757; Wed, 9 Sep 2009 14:29:02 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F18178FC16; Wed, 9 Sep 2009 14:29:01 +0000 (UTC) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n89ET1jx010634; Wed, 9 Sep 2009 14:29:01 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n89ET1Ce010630; Wed, 9 Sep 2009 14:29:01 GMT (envelope-from gavin) Date: Wed, 9 Sep 2009 14:29:01 GMT Message-Id: <200909091429.n89ET1Ce010630@freefall.freebsd.org> To: gaurav0287@gmail.com, gavin@FreeBSD.org, gavin@FreeBSD.org, freebsd-net@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/138652: TCP window scaling value calculated incorrectly? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 14:29:02 -0000 Old Synopsis: TCP window scaling value New Synopsis: TCP window scaling value calculated incorrectly? State-Changed-From-To: feedback->open State-Changed-By: gavin State-Changed-When: Wed Sep 9 14:24:24 UTC 2009 State-Changed-Why: Over to maintainer(s) for investigation Responsible-Changed-From-To: gavin->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Wed Sep 9 14:24:24 UTC 2009 Responsible-Changed-Why: Feedback was received, thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=138652 From owner-freebsd-net@FreeBSD.ORG Wed Sep 9 14:29:56 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FEAF1065672; Wed, 9 Sep 2009 14:29:56 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 46D668FC1D; Wed, 9 Sep 2009 14:29:56 +0000 (UTC) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n89ETu6S010699; Wed, 9 Sep 2009 14:29:56 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n89ETujh010695; Wed, 9 Sep 2009 14:29:56 GMT (envelope-from linimon) Date: Wed, 9 Sep 2009 14:29:56 GMT Message-Id: <200909091429.n89ETujh010695@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/138660: [igb] igb driver troubles in 8.0-BETA4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 14:29:56 -0000 Old Synopsis: igb driver troubles in 8.0-BETA4 New Synopsis: [igb] igb driver troubles in 8.0-BETA4 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Sep 9 14:29:34 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138660 From owner-freebsd-net@FreeBSD.ORG Wed Sep 9 14:30:02 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA44E1065692 for ; Wed, 9 Sep 2009 14:30:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BC56F8FC14 for ; Wed, 9 Sep 2009 14:30:02 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n89EU2Xi010763 for ; Wed, 9 Sep 2009 14:30:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n89EU2Rn010762; Wed, 9 Sep 2009 14:30:02 GMT (envelope-from gnats) Date: Wed, 9 Sep 2009 14:30:02 GMT Message-Id: <200909091430.n89EU2Rn010762@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Gaurav Goel Cc: Subject: Re: kern/138652: TCP window scaling value X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gaurav Goel List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 14:30:03 -0000 The following reply was made to PR kern/138652; it has been noted by GNATS. From: Gaurav Goel To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/138652: TCP window scaling value Date: Wed, 9 Sep 2009 19:19:58 +0530 --000feaef6808cf00280473255b4d Content-Type: text/plain; charset=UTF-8 Dear Gavin, Version- Revision *1.192.2.1 *(check it on link " http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_usrreq.c") File- "src/sys/netinet/tcp_usrreq.c" Line No- 1101 Problem described as above Thanks, Gaurav Goel On Wed, Sep 9, 2009 at 6:13 PM, wrote: > Synopsis: TCP window scaling value > > State-Changed-From-To: open->feedback > State-Changed-By: gavin > State-Changed-When: Wed Sep 9 12:38:16 UTC 2009 > State-Changed-Why: > To submitter: Firstly, tcp_input.c-orig is not a file distributed with > FreeBSD. I suspect this is left over from a failed patch attempt to > src/sys/netinet/tcp_input.c. Can you confirm that the problem exists > in that file? Can you also please give the version number of the copy > you are looking at, and the line numbers where the problem occurs? > Thanks! > > > Responsible-Changed-From-To: freebsd-bugs->gavin > Responsible-Changed-By: gavin > Responsible-Changed-When: Wed Sep 9 12:38:16 UTC 2009 > Responsible-Changed-Why: > Track > > http://www.freebsd.org/cgi/query-pr.cgi?pr=138652 > -- Gaurav Goel --000feaef6808cf00280473255b4d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Gavin,

Version- Revision 1.192.2.1 (check it on link &qu= ot;http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_usrreq.c")
File- "src/sys/netinet/tcp_usrreq.c"
Line No- 1101

Prob= lem described as above

Thanks,
Gaurav Goel

On Wed, Sep 9, 2009 at 6:13 PM, <gavin@freebsd.org> wrote:
Synopsis: TCP win= dow scaling value

State-Changed-From-To: open->feedback
State-Changed-By: gavin
State-Changed-When: Wed Sep 9 12:38:16 UTC 2009
State-Changed-Why:
To submitter: Firstly, tcp_input.c-orig is not a file distributed with
FreeBSD. =C2=A0I suspect this is left over from a failed patch attempt to src/sys/netinet/tcp_input.c. =C2=A0Can you confirm that the problem exists<= br> in that file? =C2=A0Can you also please give the version number of the copy=
you are looking at, and the line numbers where the problem occurs?
Thanks!


Responsible-Changed-From-To: freebsd-bugs->gavin
Responsible-Changed-By: gavin
Responsible-Changed-When: Wed Sep 9 12:38:16 UTC 2009
Responsible-Changed-Why:
Track

http://www.freebsd.org/cgi/query-pr.cgi?pr=3D138652



--
Gaurav Goel
--000feaef6808cf00280473255b4d-- From owner-freebsd-net@FreeBSD.ORG Wed Sep 9 15:17:13 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 379DF1065692 for ; Wed, 9 Sep 2009 15:17:13 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 05DC98FC16 for ; Wed, 9 Sep 2009 15:17:12 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n89FDgdf080109; Wed, 9 Sep 2009 11:13:42 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200909091513.n89FDgdf080109@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 09 Sep 2009 11:17:10 -0400 To: Barney Cordoba From: Mike Tancsa In-Reply-To: <538232.7388.qm@web63901.mail.re1.yahoo.com> References: <200909091352.n89DqQDx079631@lava.sentex.ca> <538232.7388.qm@web63901.mail.re1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: em driver input errors X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 15:17:13 -0000 At 10:19 AM 9/9/2009, Barney Cordoba wrote: >test would be to force it to 100Mb/s to see if the problem goes >away. I see you are using em1 which implies another NIC...if you >have traffic on the other lan its not much different than Also, >realize that most pciX busses are shared. So your disk and other >devices may be sharing. Its really derilect for these MB >manufacturers to sell dual gig nic systems and them wire them to a >slow bus. But its what they do. Barney The other nic is not in use right now. I tried switching them so see if one would work better than the other, but I didnt see any difference. The board is an intel http://www.intel.com/support/motherboards/server/s3000ah/ Not sure if its wired as PCI-X or just a 32bit bus. I am just popping in an em pcie nic to see if that makes a difference. I have an igb as well as bge I can try later. ---Mike >_______________________________________________ >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" -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-net@FreeBSD.ORG Wed Sep 9 15:29:01 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21F39106566C for ; Wed, 9 Sep 2009 15:29:01 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id C9ED18FC12 for ; Wed, 9 Sep 2009 15:29:00 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n89FPUv3080170; Wed, 9 Sep 2009 11:25:30 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200909091525.n89FPUv3080170@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 09 Sep 2009 11:28:58 -0400 To: Barney Cordoba From: Mike Tancsa In-Reply-To: <200909091513.n89FDgdf080109@lava.sentex.ca> References: <200909091352.n89DqQDx079631@lava.sentex.ca> <538232.7388.qm@web63901.mail.re1.yahoo.com> <200909091513.n89FDgdf080109@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: em driver input errors X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 15:29:01 -0000 At 11:17 AM 9/9/2009, Mike Tancsa wrote: >The board is an intel > >http://www.intel.com/support/motherboards/server/s3000ah/ > >Not sure if its wired as PCI-X or just a 32bit bus. I am just >popping in an em pcie nic to see if that makes a difference. I have >an igb as well as bge I can try later. OK, now there is em0@pci0:5:0:0: class=0x020000 card=0xa01f8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled em0: port 0x3000-0x301f mem 0xea680000-0xea69ffff,0xea600000-0xea67ffff,0xea6a0000-0xea6a3fff irq 16 at device 0.0 on pci5 em0: Using MSIX interrupts em0: [ITHREAD] em0: [ITHREAD] em0: [ITHREAD] em0: Ethernet address: .... 0[backup3]# vmstat -i interrupt total rate irq1: atkbd0 6 0 irq4: sio0 692 1 irq16: twa0 uhci3 3841 10 irq18: arcmsr0+ 7825 20 irq19: uhci1+ 13144 34 irq23: uhci0 ehci0 1 0 cpu0: timer 755553 1988 irq256: em0 3890 10 irq257: em0 3607 9 irq258: em0 1 0 cpu1: timer 745924 1962 cpu2: timer 747100 1966 cpu3: timer 747671 1967 Total 3029255 7971 Lets see how it does :) ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-net@FreeBSD.ORG Wed Sep 9 19:04:53 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E56BD1065694; Wed, 9 Sep 2009 19:04:53 +0000 (UTC) (envelope-from universite@ukr.net) Received: from mary-teresa.otrada.od.ua (universite.broker.freenet6.net [IPv6:2001:5c0:1400:b::27e9]) by mx1.freebsd.org (Postfix) with ESMTP id 4811A8FC23; Wed, 9 Sep 2009 19:04:53 +0000 (UTC) Received: from phenom (mary-teresa.otrada.od.ua [10.0.0.10]) (authenticated bits=0) by mary-teresa.otrada.od.ua (8.14.3/8.14.3) with ESMTP id n89J4kaK018512; Wed, 9 Sep 2009 22:04:46 +0300 (EEST) (envelope-from universite@ukr.net) X-Authentication-Warning: mary-teresa.otrada.od.ua: Host mary-teresa.otrada.od.ua [10.0.0.10] claimed to be phenom X-AntiVirus: Checked by Dr.Web [version: 5.0, engine: 5.00.0.12182, virus records: 632302, updated: 8.09.2009] Message-ID: <4AA7FC4B.6090601@ukr.net> Date: Wed, 09 Sep 2009 22:04:43 +0300 From: "Vladislav V. Prodan" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mary-teresa.otrada.od.ua Cc: "Li, Qing" Subject: misc/138676: after buildworld not work local routes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 19:04:54 -0000 >Number: 138676 >Category: misc >Synopsis: after buildworld not work local routes >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Sep 09 19:00:04 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Vladislav V. Prodan >Release: FreeBSD 8.0-BETA4 #0: Wed Sep 9 00:53:41 EEST 2009 amd64 >Organization: >Environment: FreeBSD mary-teresa.otrada.od.ua 8.0-BETA4 FreeBSD 8.0-BETA4 #0: Wed Sep 9 00:53:41 EEST 2009 vlad11@mary-teresa.otrada.od.ua:/usr/obj/usr/src/sys/mary-teresa.17 amd64 >Description: home PC --> FreeBSD [ squid --> apache ] These url are on the external interface of the server. http://otrada.od.ua/blog/ http://otrada.od.ua/phpmyadmin/ http://otrada.od.ua/cacti/ After upgrade the system now gives the squid: (51) Network is unreachable In logs: sep 9 18:39:10 128 10.0.0.10 TCP_MISS/503 1317 GET http://otrada.od.ua/blog/ - DIRECT/otrada.od.ua text/html sep 9 18:39:18 126 10.0.0.10 TCP_MISS/503 1329 GET http://otrada.od.ua/phpmyadmin/ - DIRECT/otrada.od.ua text/html sep 9 18:39:39 117 10.0.0.10 TCP_MISS/503 1319 GET http://otrada.od.ua/cacti/ - DIRECT/otrada.od.ua text/html Out all three url normally give details. At queries from outside, all url are working properly. similar problem was previously: http://lists.freebsd.org/pipermail/freebsd-current/2008-December/001581.html >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-net@FreeBSD.ORG Wed Sep 9 19:14:47 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 133AB106568B; Wed, 9 Sep 2009 19:14:47 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id D52438FC17; Wed, 9 Sep 2009 19:14:46 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n89JEjh8028185; Wed, 9 Sep 2009 12:14:46 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Sep 2009 12:14:05 -0700 Message-ID: In-Reply-To: <4AA7FC4B.6090601@ukr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: misc/138676: after buildworld not work local routes Thread-Index: AcoxgGl3fFVgb6TdSu6Qmv4F21vCRwAAS9lA References: <4AA7FC4B.6090601@ukr.net> From: "Li, Qing" To: "Vladislav V. Prodan" , , Cc: Subject: RE: misc/138676: after buildworld not work local routes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 19:14:47 -0000 Thanks for the report. I will work you off list for now. -- Qing > -----Original Message----- > From: Vladislav V. Prodan [mailto:universite@ukr.net] > Sent: Wednesday, September 09, 2009 12:05 PM > To: freebsd-current@freebsd.org; freebsd-net@freebsd.org > Cc: Li, Qing > Subject: misc/138676: after buildworld not work local routes >=20 > >Number: 138676 > >Category: misc > >Synopsis: after buildworld not work local routes > >Confidential: no > >Severity: serious > >Priority: medium > >Responsible: freebsd-bugs > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Wed Sep 09 19:00:04 UTC 2009 > >Closed-Date: > >Last-Modified: > >Originator: Vladislav V. Prodan > >Release: FreeBSD 8.0-BETA4 #0: Wed Sep 9 00:53:41 EEST 2009 > amd64 > >Organization: > >Environment: > FreeBSD mary-teresa.otrada.od.ua 8.0-BETA4 FreeBSD 8.0-BETA4 #0: Wed > Sep > 9 00:53:41 EEST 2009 > vlad11@mary-teresa.otrada.od.ua:/usr/obj/usr/src/sys/mary-teresa.17 > amd64 >=20 > >Description: > home PC --> FreeBSD [ squid --> apache ] >=20 > These url are on the external interface of the server. > http://otrada.od.ua/blog/ > http://otrada.od.ua/phpmyadmin/ > http://otrada.od.ua/cacti/ >=20 > After upgrade the system now gives the squid: > (51) Network is unreachable >=20 > In logs: > sep 9 18:39:10 128 10.0.0.10 TCP_MISS/503 1317 GET > http://otrada.od.ua/blog/ - DIRECT/otrada.od.ua text/html > sep 9 18:39:18 126 10.0.0.10 TCP_MISS/503 1329 GET > http://otrada.od.ua/phpmyadmin/ - DIRECT/otrada.od.ua text/html > sep 9 18:39:39 117 10.0.0.10 TCP_MISS/503 1319 GET > http://otrada.od.ua/cacti/ - DIRECT/otrada.od.ua text/html >=20 > Out all three url normally give details. > At queries from outside, all url are working properly. >=20 > similar problem was previously: > http://lists.freebsd.org/pipermail/freebsd-current/2008- > December/001581.html > >How-To-Repeat: >=20 > >Fix: >=20 >=20 > >Release-Note: > >Audit-Trail: > >Unformatted: >=20 >=20 >=20 >=20 From owner-freebsd-net@FreeBSD.ORG Wed Sep 9 19:21:02 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77BFA1065672; Wed, 9 Sep 2009 19:21:02 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4DA328FC0C; Wed, 9 Sep 2009 19:21:02 +0000 (UTC) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n89JL2FO014989; Wed, 9 Sep 2009 19:21:02 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n89JL2wr014985; Wed, 9 Sep 2009 19:21:02 GMT (envelope-from linimon) Date: Wed, 9 Sep 2009 19:21:02 GMT Message-Id: <200909091921.n89JL2wr014985@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/138666: [multicast] [panic] not working multicast through igmpproxy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 19:21:02 -0000 Old Synopsis: Do not working multicast through igmpproxy New Synopsis: [multicast] [panic] not working multicast through igmpproxy Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Sep 9 19:19:45 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138666 From owner-freebsd-net@FreeBSD.ORG Wed Sep 9 19:23:57 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CC6B106566B; Wed, 9 Sep 2009 19:23:57 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D80AE8FC0A; Wed, 9 Sep 2009 19:23:56 +0000 (UTC) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n89JNuHI015162; Wed, 9 Sep 2009 19:23:56 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n89JNuvu015158; Wed, 9 Sep 2009 19:23:56 GMT (envelope-from linimon) Date: Wed, 9 Sep 2009 19:23:56 GMT Message-Id: <200909091923.n89JNuvu015158@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/138676: [route] after buildworld not work local routes [regression] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 19:23:57 -0000 Old Synopsis: after buildworld not work local routes New Synopsis: [route] after buildworld not work local routes [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Sep 9 19:23:00 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138676 From owner-freebsd-net@FreeBSD.ORG Wed Sep 9 19:39:16 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65B3C1065695 for ; Wed, 9 Sep 2009 19:39:16 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from core.tav.kiev.ua (tavex.colocall.com [62.149.10.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0BA038FC12 for ; Wed, 9 Sep 2009 19:39:15 +0000 (UTC) Received: from [76.77.86.2] (helo=[10.80.5.136]) by core.tav.kiev.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1MlShq-000CmX-2B for freebsd-net@freebsd.org; Wed, 09 Sep 2009 22:19:50 +0300 Message-ID: <4AA7FFC0.6070302@bluezbox.com> Date: Wed, 09 Sep 2009 12:19:28 -0700 From: Oleksandr Tymoshenko User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Core-Spam-Level: + X-Core-Spam-Report: Spam detection software, running on the system "core.tav.kiev.ua", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: r196714 breaks NFSROOT in -CURRENT. When nfsclient tries to initialize interface calling ifioctl at nfsclient/nfs_vfsops.c:466 it fails with EEXIST (because route is already present I guess). I fixed it in my tree by checking for error code in mount_nfsroot, but may be it's ifioctl(SIOCAIFADDR) that should handle this case. [...] Content analysis details: (1.5 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP 4.0 BAYES_95 BODY: Bayesian spam probability is 95 to 99% [score: 0.9630] -0.7 AWL AWL: From: address is in the auto white-list Subject: NFSROOT is broken after r196714 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 19:39:16 -0000 r196714 breaks NFSROOT in -CURRENT. When nfsclient tries to initialize interface calling ifioctl at nfsclient/nfs_vfsops.c:466 it fails with EEXIST (because route is already present I guess). I fixed it in my tree by checking for error code in mount_nfsroot, but may be it's ifioctl(SIOCAIFADDR) that should handle this case. -- gonzo From owner-freebsd-net@FreeBSD.ORG Wed Sep 9 19:47:52 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B271106568F for ; Wed, 9 Sep 2009 19:47:52 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 541308FC08 for ; Wed, 9 Sep 2009 19:47:52 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n89JkKMD002959; Wed, 9 Sep 2009 12:47:13 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Sep 2009 12:47:07 -0700 Message-ID: In-Reply-To: <4AA7FFC0.6070302@bluezbox.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NFSROOT is broken after r196714 Thread-Index: AcoxhUPQHdyiNh4CQ9qVuDz0QDxQVQAAI2fg References: <4AA7FFC0.6070302@bluezbox.com> From: "Li, Qing" To: "Oleksandr Tymoshenko" , Cc: Subject: RE: NFSROOT is broken after r196714 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 19:47:52 -0000 Do you know what IP address nfsclient/nfs_vfsops.c:466 is trying to=20 insert and do you have an output of the "ifconfig" and route=20 table you can send to me privately? At the moment I am suspecting r196714 uncovered an issue that has always been there. But that's an assumption at the moment. Thanks, -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Oleksandr Tymoshenko > Sent: Wednesday, September 09, 2009 12:19 PM > To: freebsd-net@freebsd.org > Subject: NFSROOT is broken after r196714 >=20 > r196714 breaks NFSROOT in -CURRENT. When nfsclient tries to > initialize interface calling ifioctl at nfsclient/nfs_vfsops.c:466 > it fails with EEXIST (because route is already present I guess). >=20 > I fixed it in my tree by checking for error code in mount_nfsroot, > but may be it's ifioctl(SIOCAIFADDR) that should handle this case. >=20 > -- > gonzo > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Sep 9 20:06:34 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6348D106568D; Wed, 9 Sep 2009 20:06:34 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3A6D48FC22; Wed, 9 Sep 2009 20:06:34 +0000 (UTC) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n89K6YFw054694; Wed, 9 Sep 2009 20:06:34 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n89K6YwU054690; Wed, 9 Sep 2009 20:06:34 GMT (envelope-from linimon) Date: Wed, 9 Sep 2009 20:06:34 GMT Message-Id: <200909092006.n89K6YwU054690@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/138678: [lo] FreeBSD does not assign linklocal address to loopbacks >0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 20:06:34 -0000 Old Synopsis: FreeBSD does not assign linklocal address to loopbacks >0 New Synopsis: [lo] FreeBSD does not assign linklocal address to loopbacks >0 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Sep 9 20:05:49 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138678 From owner-freebsd-net@FreeBSD.ORG Wed Sep 9 20:20:05 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4E3A106568B for ; Wed, 9 Sep 2009 20:20:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 93FCB8FC15 for ; Wed, 9 Sep 2009 20:20:05 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n89KK5dL065435 for ; Wed, 9 Sep 2009 20:20:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n89KK5Xb065434; Wed, 9 Sep 2009 20:20:05 GMT (envelope-from gnats) Date: Wed, 9 Sep 2009 20:20:05 GMT Message-Id: <200909092020.n89KK5Xb065434@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Vladislav V. Prodan" Cc: Subject: Re: misc/138676: after buildworld not work local routes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Vladislav V. Prodan" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 20:20:05 -0000 The following reply was made to PR kern/138676; it has been noted by GNATS. From: "Vladislav V. Prodan" To: "Li, Qing" , freebsd-current@freebsd.org Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: misc/138676: after buildworld not work local routes Date: Wed, 09 Sep 2009 23:18:34 +0300 Li, Qing пишет: > Okay, perhaps I didn't understand your issue correctly. In > http://lists.freebsd.org/pipermail/freebsd-current/2008-December/001581.html > the errors are route insertion related. Those routes are not > visible inside the kernel. Now these routes show up in the > table but Squid reports > " After upgrade the system now gives the squid: > (51) Network is unreachable" > Which IP address is not reachable? Do not operate sites on IP 89.209.81.54, when you walk through the squid. If you go to the sites, bypassing squid, then everything works. It seems, squid does not "see" the table of the form: Destination Gateway Flags Refs Use Netif Expire 89.209.81.54 link#4 UHS 0 30161 lo0 From owner-freebsd-net@FreeBSD.ORG Wed Sep 9 21:11:29 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BA70106566B for ; Wed, 9 Sep 2009 21:11:29 +0000 (UTC) (envelope-from stef-list@memberwebs.com) Received: from mail.npubs.com (mail.npubs.com [74.82.45.72]) by mx1.freebsd.org (Postfix) with ESMTP id 0B92B8FC16 for ; Wed, 9 Sep 2009 21:11:28 +0000 (UTC) Resent-Message-Id: From: Stef Walter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "freebsd-net@FreeBSD.org" Content-Type: multipart/mixed; boundary="------------090905060408000505030902" X-Virus-Scanned: ClamAV using ClamSMTP Resent-Date: Wed, 9 Sep 2009 21:11:29 +0000 (UTC) Resent-From: stef-list@memberwebs.com Subject: [patch] Multicast: uninited memory used in filter at IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stef@memberwebs.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 09 Sep 2009 21:11:29 -0000 X-List-Received-Date: Wed, 09 Sep 2009 21:11:29 -0000 This is a multi-part message in MIME format. --------------090905060408000505030902 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit If a multicast caller does an IP_DROP_MEMBERSHIP followed by a IP_ADD_MEMBERSHIP, often an uninitialized filter is used for the in_mfilter passed to in_joingroup_locked() in netinet/in_mcast.c. The IP_ADD_MEMBERSHIP and IP_DROP_MEMBERSHIP have simple in_mreq input, and are not using SSM or any of the new IGMPv3 features. This results in the following behavior shown by ifmcstat. Before the drop + add you can see the following groups for the northstar1 interface. Note that 224.0.0.5 (ie: OSPF-ALL.MCAST.NET) is subscribed with an empty exclude filter as you would expect from simple ASM mode: > # ifmcstat -i northstar1 > northstar1: > inet 172.28.1.66 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.5 mode exclude > group 224.0.0.1 mode exclude After the drop + add, it looks like the following. Note that now 224.0.0.5 is subscribed with an empty *include* filter which results in no packets received. > # ifmcstat -i northstar1 > northstar1: > inet 172.28.1.66 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.1 mode exclude > group 224.0.0.5 mode include uname: FreeBSD portillo-gate.ws.local 8.0-BETA3 FreeBSD 8.0-BETA3 #24: Wed Sep 9 15:01:39 UTC 2009 root@portillo-gate.ws.local:/usr/src/sys/i386/compile/PORTILLO i386 Patch is attached which fixes the problem. Is this the right approach? If not, I hope it helps highlight the problem area. Cheers, Stef --------------090905060408000505030902 Content-Type: text/x-diff; name="freebsd-mcast-uninited.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="freebsd-mcast-uninited.patch" --- sys/netinet/in_mcast.c.orig 2009-08-03 08:13:06.000000000 +0000 +++ sys/netinet/in_mcast.c 2009-09-09 15:01:24.000000000 +0000 @@ -2024,6 +2050,9 @@ error = ENOMEM; goto out_imo_free; } + } else if (is_new) { + /* Old style ASM filter mode is always exclude */ + imf_init(imf, MCAST_UNDEFINED, MCAST_EXCLUDE); } /* --------------090905060408000505030902-- From owner-freebsd-net@FreeBSD.ORG Wed Sep 9 22:54:49 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 183C71065693 for ; Wed, 9 Sep 2009 22:54:49 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id DF1A68FC16 for ; Wed, 9 Sep 2009 22:54:48 +0000 (UTC) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 240D969080; Wed, 9 Sep 2009 18:54:47 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 09 Sep 2009 18:54:47 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:cc:subject:content-type:content-transfer-encoding; s=smtpout; bh=t0qyLM+vI5fD+tF3/5fEv4+/8Qg=; b=l3Rnn4UF+2BFyJC1dZPm/acLoLNCn+i17niWL9DrGbcImaM/+AvUwyI+AVLXjkwK9ja1B02WwLas4np8VxTkKrpol52HVbrDB+k/itk9YQ88ovBmcC9VfGD2h9G2Qm992XIY0p57GNVWmnKyoJrPpCTNx7DPUxM7EuMIwDsDW7c= X-Sasl-enc: cR7RHB5aSVVJAJ1M4UHnLeaVA/O9FpKPD+4v8XD57Pv8 1252536886 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 7971C5A55; Wed, 9 Sep 2009 18:54:46 -0400 (EDT) Message-ID: <4AA83230.4070405@incunabulum.net> Date: Wed, 09 Sep 2009 23:54:40 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: stef@memberwebs.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@FreeBSD.org" Subject: Re: [patch] Multicast: uninited memory used in filter at IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 22:54:49 -0000 Stef Walter wrote: > ... > Patch is attached which fixes the problem. Is this the right approach? > If not, I hope it helps highlight the problem area. > Good catch; thanks for the fix. I used to depend on imf being initialized to NULL in this function, however, I opted to keep the old vector-style allocation scheme for in_mfilter and track it with in_multi on the socket. If the descriptor slot got recycled, then the imf contents will be invalid as you saw. I think this can probably go right in as-is. I'm supposed to be looking at other stuff now, so hopefully syrinx@ can check this in if I don't get around to it. thanks, BMS From owner-freebsd-net@FreeBSD.ORG Wed Sep 9 23:42:17 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56FCD106566C for ; Wed, 9 Sep 2009 23:42:17 +0000 (UTC) (envelope-from stef-list@memberwebs.com) Received: from mail.npubs.com (mail.npubs.com [74.82.45.72]) by mx1.freebsd.org (Postfix) with ESMTP id 48ECE8FC17 for ; Wed, 9 Sep 2009 23:42:17 +0000 (UTC) Resent-Message-Id: From: Stef Walter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Bruce Simpson References: <4AA83230.4070405@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Resent-Date: Wed, 9 Sep 2009 23:42:17 +0000 (UTC) Resent-From: stef-list@memberwebs.com Cc: "freebsd-net@FreeBSD.org" Subject: Re: [patch] Multicast: uninited memory used in filter at IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stef@memberwebs.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 09 Sep 2009 23:42:17 -0000 X-List-Received-Date: Wed, 09 Sep 2009 23:42:17 -0000 Bruce Simpson wrote: > I think this can probably go right in as-is. I'm supposed to be looking > at other stuff now, so hopefully syrinx@ can check this in if I don't > get around to it. Great news. Should I just make a PR for this? Or is there somewhere I should put it for the 8.0 BETA? After these various (posted) multicast patches OSPF (with quagga) is now far more stable on 8.0-BETA4. However I'm still seeing intermittent problems. I need help in knowing how to debug the following. Once it's figured out, I'd like to make a patch. Specifically: Quagga has a sockets open on em0, portillo1, and northstar1 below on the 224.0.0.5 group. ifmcstat output: > em0: > inet 172.27.2.1 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.5 mode exclude > mcast-macaddr 01:00:5e:00:00:05 > group 224.0.0.1 mode exclude > mcast-macaddr 01:00:5e:00:00:01 > em1: > inet 189.162.25.187 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.1 mode exclude > mcast-macaddr 01:00:5e:00:00:01 > lo0: > inet 127.0.0.1 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.1 mode exclude > inet6 fe80::1%lo0 > mldv2 flags=0<> rv 2 qi 125 qri 10 uri 3 > group ff01::1%lo0 mode exclude > group ff02::2:10c2:bd48%lo0 mode exclude > group ff02::1%lo0 mode exclude > group ff02::1:ff00:1%lo0 mode exclude > leaseweb0: > inet 10.94.75.3 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.1 mode exclude > mcast-macaddr 01:00:5e:00:00:01 > portillo1: > inet 172.28.1.65 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.5 mode exclude > group 224.0.0.1 mode exclude > eaglecrest1: > inet 172.28.1.70 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.5 mode exclude > group 224.0.0.1 mode exclude After a while and a few interface ups and downs, quagga stops getting OSPF packets on one of the interfaces. I can verify with tcpdump that these packets are seen by the machine. For example, on em0: > # tcpdump -pnti em0 proto ospf > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes > IP 172.27.2.1 > 224.0.0.5: OSPFv2, Hello, length 44 > IP 172.27.2.2 > 224.0.0.5: OSPFv2, Hello, length 48 > IP 172.27.2.1 > 224.0.0.5: OSPFv2, Hello, length 44 > IP 172.27.2.2 > 224.0.0.5: OSPFv2, Hello, length 48 > IP 172.27.2.1 > 224.0.0.5: OSPFv2, Hello, length 44 > IP 172.27.2.2 > 224.0.0.5: OSPFv2, Hello, length 48 > IP 172.27.2.1 > 224.0.0.5: OSPFv2, Hello, length 44 > IP 172.27.2.2 > 224.0.0.5: OSPFv2, Hello, length 48 The packets from 172.27.2.2 are not being delivered to the ospfd process socket (verified via userland debugging and logging). Even though, as you can see above the em0 interface is part of the group. Where and how could I see what's preventing these packets from being delivered to the ospfd process socket? Which code is involved in the dispatch? Thanks for your help and time. Much appreciated. Cheers, Stef From owner-freebsd-net@FreeBSD.ORG Thu Sep 10 01:30:06 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 583481065670 for ; Thu, 10 Sep 2009 01:30:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 472A58FC0C for ; Thu, 10 Sep 2009 01:30:06 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8A1U6fc077699 for ; Thu, 10 Sep 2009 01:30:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8A1U6Es077696; Thu, 10 Sep 2009 01:30:06 GMT (envelope-from gnats) Date: Thu, 10 Sep 2009 01:30:06 GMT Message-Id: <200909100130.n8A1U6Es077696@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Bruce Cran Cc: Subject: Re: kern/64556: [sis] if_sis short cable fix problems with NetGear FA311's X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Cran List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 01:30:06 -0000 The following reply was made to PR kern/64556; it has been noted by GNATS. From: Bruce Cran To: bug-followup@FreeBSD.org, tom@hur.st Cc: Subject: Re: kern/64556: [sis] if_sis short cable fix problems with NetGear FA311's Date: Thu, 10 Sep 2009 02:24:17 +0100 I'm still seeing this problem on 8.0-BETA4. Running two ttcp's (one rx, one tx) causes the system to print lots of "Applying short cable fix" messages. I've had a look through the NetBSD driver, the original Linux driver from http://www.soekris.com/downloads.htm and also the latest Linux sources. When the issue occurs, I see throughput drop to around 5Mb. The first issues seems to be the 100ms delay. From the other code I've looked at, it looks like it should be 100us which would speed up the reset process. Secondly, it seems that only FreeBSD resets the chip when an RX overrun occurs; on NetBSD it does a printf and continues, and Linux increments the error statistics. Both only apply the short cable fix when a media change occurs. -- Bruce Cran From owner-freebsd-net@FreeBSD.ORG Thu Sep 10 03:09:32 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C6581065672 for ; Thu, 10 Sep 2009 03:09:32 +0000 (UTC) (envelope-from stef-list@memberwebs.com) Received: from mail.npubs.com (mail.npubs.com [74.82.45.72]) by mx1.freebsd.org (Postfix) with ESMTP id 6FEB48FC08 for ; Thu, 10 Sep 2009 03:09:32 +0000 (UTC) Resent-Message-Id: From: Stef Walter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Bruce Simpson References: <4AA83230.4070405@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Resent-Date: Thu, 10 Sep 2009 03:09:32 +0000 (UTC) Resent-From: stef-list@memberwebs.com Cc: "freebsd-net@FreeBSD.org" Subject: Re: Multicast SSM bug? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Thu, 10 Sep 2009 03:09:32 -0000 X-List-Received-Date: Thu, 10 Sep 2009 03:09:32 -0000 Stef Walter wrote: > The packets from 172.27.2.2 are not being delivered to the ospfd process > socket (verified via userland debugging and logging). Even though, as > you can see above the em0 interface is part of the group. I've done more research on this. Each time a packet is not delivered, I can see this counter being incremented: > # netstat -s -p ip | grep multicast > 885 packets received for unknown multicast group That counter originates from this block of code in raw_ip.c: > 354 blocked = imo_multi_filter(inp->inp_moptions, ifp, > 355 (struct sockaddr *)&group, > 356 (struct sockaddr *)&ripsrc); > 357 if (blocked != MCAST_PASS) { > 358 IPSTAT_INC(ips_notmember); > 359 continue; > 360 } After instrumenting it with this printf: > printf("not member: group = %s, ", inet_ntoa (group.sin_addr)); > printf("src = %s, why = %d\n", inet_ntoa (ripsrc.sin_addr), (int)blocked); Then wait, then up down some interfaces, etc.... quagga adds/drops memberships, eventually I see the following output: > not member: group = 224.0.0.5, src = 172.28.1.66, why = 2 > not member: group = 224.0.0.5, src = 172.28.1.66, why = 2 > not member: group = 224.0.0.5, src = 172.28.1.66, why = 2 > not member: group = 224.0.0.5, src = 172.28.1.66, why = 2 > not member: group = 224.0.0.5, src = 172.28.1.66, why = 2 > not member: group = 224.0.0.5, src = 172.28.1.66, why = 2 The why = 2 is MCAST_NOTSMEMBER. 172.28.1.66 is the tunnel peer sending OSPF multicast packets. Somehow imo_multi_filter is limiting via packet source for this membership. However, this is what the interface looks like via ifmcstat (ie: no SSM memberships): > portillo1: > inet 172.28.1.65 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.5 mode exclude > group 224.0.0.1 mode exclude Any of the above ring a bell? If not, I'll keep poking around and see what I find. Cheers, Stef From owner-freebsd-net@FreeBSD.ORG Thu Sep 10 05:21:36 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDC34106566B for ; Thu, 10 Sep 2009 05:21:36 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id A187B8FC12 for ; Thu, 10 Sep 2009 05:21:36 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mlc6B-000H17-Vx for freebsd-net@FreeBSD.org; Thu, 10 Sep 2009 05:21:36 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 8F31B29D4FC7 for ; Wed, 9 Sep 2009 22:21:35 -0700 (PDT) Date: Wed, 09 Sep 2009 22:21:35 -0700 Message-ID: From: Randy Bush To: freebsd-net User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: forwarding when two rip defaults X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 05:21:37 -0000 say i run routed and receive rip default from two routers, on the same local ether. what is the forwarding? i presume it's not smart enough to balance flows. i hope not alternating packets. clue, please? fwiw, the routers each have full bgp exits. vrrp would force all traffic to one. so i am looking at rip or quagga's isisd. thanks. randy From owner-freebsd-net@FreeBSD.ORG Thu Sep 10 05:31:51 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9E1A106568F for ; Thu, 10 Sep 2009 05:31:51 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outX.internet-mail-service.net (outx.internet-mail-service.net [216.240.47.247]) by mx1.freebsd.org (Postfix) with ESMTP id B34B78FC0A for ; Thu, 10 Sep 2009 05:31:51 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 60D17B647; Wed, 9 Sep 2009 22:31:57 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (c-98-248-144-128.hsd1.ca.comcast.net [98.248.144.128]) by idiom.com (Postfix) with ESMTP id 144C32D6004; Wed, 9 Sep 2009 22:31:51 -0700 (PDT) Message-ID: <4AA88F45.8000407@elischer.org> Date: Wed, 09 Sep 2009 22:31:49 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Randy Bush References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net Subject: Re: forwarding when two rip defaults X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 05:31:51 -0000 Randy Bush wrote: > say i run routed and receive rip default from two routers, on the same > local ether. what is the forwarding? i presume it's not smart enough > to balance flows. i hope not alternating packets. clue, please? > > fwiw, the routers each have full bgp exits. vrrp would force all > traffic to one. so i am looking at rip or quagga's isisd. > > thanks. > > randy > _______________________________________________ > 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" I can't speak for routed but the base system, given two default routes would use a hashing schemem to send data to both. more details depend on what options you have turned on. From owner-freebsd-net@FreeBSD.ORG Thu Sep 10 05:35:45 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5077A106566B for ; Thu, 10 Sep 2009 05:35:45 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 32B7F8FC17 for ; Thu, 10 Sep 2009 05:35:45 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlcJs-000H3N-52; Thu, 10 Sep 2009 05:35:44 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id AF82529D5197; Wed, 9 Sep 2009 22:35:43 -0700 (PDT) Date: Wed, 09 Sep 2009 22:35:43 -0700 Message-ID: From: Randy Bush To: Julian Elischer In-Reply-To: <4AA88F45.8000407@elischer.org> References: <4AA88F45.8000407@elischer.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net Subject: Re: forwarding when two rip defaults X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 05:35:45 -0000 >> say i run routed and receive rip default from two routers, on the same >> local ether. what is the forwarding? i presume it's not smart enough >> to balance flows. i hope not alternating packets. clue, please? > I can't speak for routed routed is just the routing protocol used to garner the routes installed in the fib. so it should not be of concern. > the base system, given two default routes would use a hashing schemem > to send data to both. more details depend on what options you have > turned on. is there a doc page somewhere? thanks. randy From owner-freebsd-net@FreeBSD.ORG Thu Sep 10 05:58:58 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B41A31065672 for ; Thu, 10 Sep 2009 05:58:58 +0000 (UTC) (envelope-from stef-list@memberwebs.com) Received: from mail.npubs.com (mail.npubs.com [74.82.45.72]) by mx1.freebsd.org (Postfix) with ESMTP id A43138FC14 for ; Thu, 10 Sep 2009 05:58:58 +0000 (UTC) Resent-Message-Id: From: Stef Walter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "freebsd-net@FreeBSD.org" Content-Type: multipart/mixed; boundary="------------010308080209070707080404" X-Virus-Scanned: ClamAV using ClamSMTP Resent-Date: Thu, 10 Sep 2009 05:58:58 +0000 (UTC) Resent-From: stef-list@memberwebs.com Subject: [patch] Multicast: Keep membership and filters in sync X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stef@memberwebs.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Thu, 10 Sep 2009 05:58:58 -0000 X-List-Received-Date: Thu, 10 Sep 2009 05:58:58 -0000 This is a multi-part message in MIME format. --------------010308080209070707080404 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit When removing multicast membership from a socket (ie: IP_DROP_MEMBERSHIP) that has multiple multicast memberships, the internal list of memberships and filters are not kept in sync. This results in dropped packets that are not delivered to the socket that has the multicast membership. This was experienced with OSPF (running quagga). Besides the obvious non-functional multicast, the following command is another way to see an indication of the problem: > # netstat -s -p ip | grep multicast > 7 packets received for unknown multicast group Patch attached which fixes the problem. Cheers, Stef --------------010308080209070707080404 Content-Type: text/x-diff; name="freebsd-mcast-filter-array-in-sync.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="freebsd-mcast-filter-array-in-sync.patch" --- sys/netinet/in_mcast.c.orig 2009-09-09 19:33:22.000000000 +0000 +++ sys/netinet/in_mcast.c 2009-09-10 05:28:20.000000000 +0000 @@ -2280,7 +2292,9 @@ if (is_final) { - /* Remove the gap in the membership array. */ - for (++idx; idx < imo->imo_num_memberships; ++idx) + /* Remove the gap in the membership and filter array. */ + for (++idx; idx < imo->imo_num_memberships; ++idx) { imo->imo_membership[idx-1] = imo->imo_membership[idx]; + imo->imo_mfilters[idx-1] = imo->imo_mfilters[idx]; + } imo->imo_num_memberships--; } --------------010308080209070707080404-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 10 06:05:48 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 760FB106566C for ; Thu, 10 Sep 2009 06:05:48 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 5F7558FC1C for ; Thu, 10 Sep 2009 06:05:48 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n8A65lX6009928; Wed, 9 Sep 2009 23:05:47 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Sep 2009 22:57:54 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: forwarding when two rip defaults Thread-Index: Acox1qmwbIoIutjIRG+1Mskg6Emm6AABO57Q References: From: "Li, Qing" To: "Randy Bush" , "freebsd-net" Cc: Subject: RE: forwarding when two rip defaults X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 06:05:48 -0000 What release are you running ? -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Randy Bush > Sent: Wednesday, September 09, 2009 10:22 PM > To: freebsd-net > Subject: forwarding when two rip defaults >=20 > say i run routed and receive rip default from two routers, on the same > local ether. what is the forwarding? i presume it's not smart enough > to balance flows. i hope not alternating packets. clue, please? >=20 > fwiw, the routers each have full bgp exits. vrrp would force all > traffic to one. so i am looking at rip or quagga's isisd. >=20 > thanks. >=20 > randy > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Sep 10 07:22:26 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F11D106566B for ; Thu, 10 Sep 2009 07:22:26 +0000 (UTC) (envelope-from stef-list@memberwebs.com) Received: from mail.npubs.com (mail.npubs.com [74.82.45.72]) by mx1.freebsd.org (Postfix) with ESMTP id 629DB8FC13 for ; Thu, 10 Sep 2009 07:22:26 +0000 (UTC) Resent-Message-Id: From: Stef Walter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Randy Bush References: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Resent-Date: Thu, 10 Sep 2009 07:22:26 +0000 (UTC) Resent-From: stef-list@memberwebs.com Cc: freebsd-net Subject: Re: forwarding when two rip defaults X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stef@memberwebs.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Thu, 10 Sep 2009 07:22:26 -0000 X-List-Received-Date: Thu, 10 Sep 2009 07:22:26 -0000 Randy Bush wrote: > say i run routed and receive rip default from two routers, on the same > local ether. what is the forwarding? i presume it's not smart enough > to balance flows. i hope not alternating packets. clue, please? Unless you have RADIX_MPATH in your kernel (with a recent FreeBSD, ie: 8.0) it'll choose one at random. Unless one route has a better metric. Cheers, Stef From owner-freebsd-net@FreeBSD.ORG Thu Sep 10 07:37:40 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63E61106566C for ; Thu, 10 Sep 2009 07:37:40 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: from hal.rescomp.berkeley.edu (hal.Rescomp.Berkeley.EDU [169.229.70.150]) by mx1.freebsd.org (Postfix) with ESMTP id 479968FC08 for ; Thu, 10 Sep 2009 07:37:40 +0000 (UTC) Received: by hal.rescomp.berkeley.edu (Postfix, from userid 1225) id 9C8C4597D73; Thu, 10 Sep 2009 00:37:39 -0700 (PDT) Date: Thu, 10 Sep 2009 00:37:39 -0700 From: Chris Cowart To: George Neville-Neil Message-ID: <20090910073739.GB37291@hal.rescomp.berkeley.edu> Mail-Followup-To: George Neville-Neil , freebsd-net@freebsd.org References: <20090904223123.GD16213@hal.rescomp.berkeley.edu> <723505E9-96C6-401C-A844-3D9BA2033795@neville-neil.com> <20090907191001.GA37291@hal.rescomp.berkeley.edu> <54FDC10A-EAE3-4AE2-BF36-2C5F7D141C3A@neville-neil.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="FsscpQKzF/jJk6ya" Content-Disposition: inline In-Reply-To: <54FDC10A-EAE3-4AE2-BF36-2C5F7D141C3A@neville-neil.com> Organization: RSSP-IT, UC Berkeley User-Agent: Mutt/1.5.20 (2009-06-14) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: IPSEC + long UDP causes reproducible crash [was: Crash in ether_input] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 07:37:40 -0000 --FsscpQKzF/jJk6ya Content-Type: multipart/mixed; boundary="tsOsTdHNUZQcU9Ye" Content-Disposition: inline --tsOsTdHNUZQcU9Ye Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable George Neville-Neil wrote: > Sounds great. One more thought. Can you try this without =20 > IPSEC_FILTERTUNNEL? > Since that copies packets I'm suspicious of it. Hi, Thanks for the suggestion. Disabling IPSEC_FILTERTUNNEL does not prevent the crashes. I have been using i386 and amd64 virtual machines as well as an amd64 physical machine; this problem can be reproduced fairly reliably on all of them for 7.0 and 7.1 (and we're pretty sure we saw it in 6.x and didn't know what it was at the time). I've pared down the set of steps required to reproduce. Kernel config: | include GENERIC | ident IPSEC | options IPSEC | device crypto /etc/rc.conf: | ipsec_enable=3D"YES" | ipsec_file=3D"/etc/ipsec.conf" em0 is configured for DHCP and running on a 1500 mtu network. /etc/ipsec.conf: | add 10.1.10.234 10.1.10.235 esp 12345 -E 3des-cbc | 0x123456789012345678901234567890123456789012345678; | add 10.1.10.234 10.1.10.235 ah 22345 -A hmac-md5 | 0x12345678901234567890123456789012; |=20 | spdadd 10.1.10.234/32 10.1.10.235/32 any -P out ipsec | esp/transport//require ah/transport//require; This is a minimal IPSEC configuration to cause outbound traffic to that IP be passed through IPSEC. You don't even need to configure the other endpoint to test the crash. Earlier today, I was able to cause a crash using just esp and using just ah. Either one alone or both together exhibit the crashes. A C program that sends long UDP messages is attached (there's a hardcoded remote IP in there). The program sends 2 UDP message of size 1960, sleeping for 3 seconds in between. Most of the time, on a clean boot, the first message is enough to cause a kernel panic. The second message almost always causes a kernel panic. I have never been able to run the program a second time without the system crashing. The exact point of the panic tends to vary. I've seen it frequently occurring in in_cksumdata, but it's all been really close to ip_output. I've been poking around in the debugger for hours over the past couple of days. I can't tell if the mbuf is being corrupted as it's passing through the crypto system or if it's happening in ip_fragment. I'm in a bit over my head in terms of trying to isolate and patch the bug. If anyone has the time to squash it or at least give me some pointers as to where I might look, that would help. --=20 Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley --tsOsTdHNUZQcU9Ye-- --FsscpQKzF/jJk6ya Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iQIcBAEBAwAGBQJKqKzDAAoJEC8b9sM8ejXt9K0QAJQu0qH6HTiNeHU4OggEqM5N /xYlo2yqTWjTF1OifgLQo8Dszw+vgqLAqatsqrZsTSBeBD2t2Xoz5UsQOGe85D+N M74PM1JY9f6724UVhgo+FH6KXcrQWfdsj7kS9Yq/HPv5z8+djlrnTU0kByqP4Q18 qv05nfajzAZMhsAjvV5CX9yJc9YzfSG/PWHp0VLMZq0vQvx4AZZWaK7gfhpLa+G5 pIY15Lamk5C7e0qvpSboNmaINnL3gk2Xq/++gxkFbsKhZKqH2YukUqRAB0ryCM+A vZ56NTfs9B4F0qmNstGzaMKVLWOMdgp2+ZqNWAyvopqAqcu1kp7lyoE+LdoMEDWX dOxxCXe9V0IEDES5yfKJjuy0RHnqLNjwIz3vHNGPLVkjMsi+ejj3X/1EnTPevp3r SsgInB2ZpZtDTURGJ1JTSNc8iqF+menJawBSII8T2vcING+DFcqwf/4lG+jUG2iQ ur57M/z+EnIanyh1bm1ppILAuAxNEJ0GOR+ZuEj7Ap1UW96VA3z/z9/5+ESj4gfD KkygvRp6je1bgYNOHbX9+GgLcR43jQXkiHZtlwNry8NK9L5elJc63Ysx6yNdlYEL Gt+cGmlgV1OF6hseH9qEraozXen/OCX8EPWf6b6TXgpr26ACvs9xs25D9VnCiE/v E12szXGOrDvgAkGkY7AT =I46C -----END PGP SIGNATURE----- --FsscpQKzF/jJk6ya-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 10 08:13:43 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 830D5106566B for ; Thu, 10 Sep 2009 08:13:43 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3A9C78FC14 for ; Thu, 10 Sep 2009 08:13:42 +0000 (UTC) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id 9DA332798BC; Thu, 10 Sep 2009 10:13:40 +0200 (CEST) Received: by astro.zen.inc (Postfix, from userid 1000) id 7178C1705D; Thu, 10 Sep 2009 10:13:37 +0200 (CEST) Date: Thu, 10 Sep 2009 10:13:37 +0200 From: VANHULLEBUS Yvan To: Chris Cowart Message-ID: <20090910081337.GA66528@zeninc.net> References: <20090904223123.GD16213@hal.rescomp.berkeley.edu> <723505E9-96C6-401C-A844-3D9BA2033795@neville-neil.com> <20090907191001.GA37291@hal.rescomp.berkeley.edu> <54FDC10A-EAE3-4AE2-BF36-2C5F7D141C3A@neville-neil.com> <20090910073739.GB37291@hal.rescomp.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090910073739.GB37291@hal.rescomp.berkeley.edu> User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-net@freebsd.org Subject: Re: IPSEC + long UDP causes reproducible crash [was: Crash in ether_input] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 08:13:43 -0000 On Thu, Sep 10, 2009 at 12:37:39AM -0700, Chris Cowart wrote: [...] > Hi, Hi. [...] > I have been using i386 and amd64 virtual machines as well as an amd64 > physical machine; this problem can be reproduced fairly reliably on all > of them for 7.0 and 7.1 (and we're pretty sure we saw it in 6.x and > didn't know what it was at the time). I fixed in FreeBSD 7.2+ a bug which looks to be related with your crashes (kernel panic with big packets), could you please try again with FreeBSD 7.2 and report us the result ? Thanks, Yvan. From owner-freebsd-net@FreeBSD.ORG Thu Sep 10 08:32:33 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF54C106568F for ; Thu, 10 Sep 2009 08:32:33 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id 7FE998FC16 for ; Thu, 10 Sep 2009 08:32:33 +0000 (UTC) Received: from baby-jane.lamaiziere.net (132.10.87-79.rev.gaoland.net [79.87.10.132]) by smtp.lamaiziere.net (Postfix) with ESMTPA id D0325633321; Thu, 10 Sep 2009 10:14:11 +0200 (CEST) Received: from baby-jane.lamaiziere.net (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id 1964EC333; Thu, 10 Sep 2009 10:14:51 +0200 (CEST) Date: Thu, 10 Sep 2009 10:14:49 +0200 From: Patrick Lamaiziere To: Chris Cowart Message-ID: <20090910101449.0fa714bd@baby-jane.lamaiziere.net> In-Reply-To: <20090910073739.GB37291@hal.rescomp.berkeley.edu> References: <20090904223123.GD16213@hal.rescomp.berkeley.edu> <723505E9-96C6-401C-A844-3D9BA2033795@neville-neil.com> <20090907191001.GA37291@hal.rescomp.berkeley.edu> <54FDC10A-EAE3-4AE2-BF36-2C5F7D141C3A@neville-neil.com> <20090910073739.GB37291@hal.rescomp.berkeley.edu> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.6; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: IPSEC + long UDP causes reproducible crash [was: Crash in ether_input] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 08:32:33 -0000 Le Thu, 10 Sep 2009 00:37:39 -0700, Chris Cowart a =E9crit : Hello, > A C program that sends long UDP messages is attached (there's a > hardcoded remote IP in there). The program sends 2 UDP message of size > 1960, sleeping for 3 seconds in between. Most of the time, on a clean > boot, the first message is enough to cause a kernel panic. The second > message almost always causes a kernel panic. I have never been able to > run the program a second time without the system crashing. >=20 > The exact point of the panic tends to vary. I've seen it frequently > occurring in in_cksumdata, but it's all been really close to > ip_output. >=20 > I've been poking around in the debugger for hours over the past couple > of days. I can't tell if the mbuf is being corrupted as it's passing > through the crypto system or if it's happening in ip_fragment. I'm in > a bit over my head in terms of trying to isolate and patch the bug. If > anyone has the time to squash it or at least give me some pointers as > to where I might look, that would help. I'm not sure if it will help, but that reminds me this problem : http://www.freebsd.org/cgi/query-pr.cgi?pr=3D124609 This is fixed in 7.1-STABLE and after. From owner-freebsd-net@FreeBSD.ORG Thu Sep 10 13:40:02 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 202A41065676 for ; Thu, 10 Sep 2009 13:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0E47C8FC13 for ; Thu, 10 Sep 2009 13:40:02 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8ADe1Vu058872 for ; Thu, 10 Sep 2009 13:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8ADe1cZ058871; Thu, 10 Sep 2009 13:40:01 GMT (envelope-from gnats) Date: Thu, 10 Sep 2009 13:40:01 GMT Message-Id: <200909101340.n8ADe1cZ058871@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Gaurav Goel Cc: Subject: Re: kern/138652: TCP window scaling value calculated incorrectly? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gaurav Goel List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 13:40:02 -0000 The following reply was made to PR kern/138652; it has been noted by GNATS. From: Gaurav Goel To: bug-followup@freebsd.org Cc: Subject: Re: kern/138652: TCP window scaling value calculated incorrectly? Date: Thu, 10 Sep 2009 19:00:37 +0530 --000feae95a4f797c710473393423 Content-Type: text/plain; charset=UTF-8 Dear Gavin, Please find the fix for the problem: *Replace* * while (tp->request_r_scale < TCP_MAX_WINSHIFT && (TCP_MAXWIN << tp->request_r_scale) < sb_max) tp->request_r_scale++;* *With* *unsigned int new_TCP_MAXWIN = TCP_MAXWIN; while (tp->request_r_scale < TCP_MAX_WINSHIFT) { if(new_TCP_MAXWIN < sb_max) tp->request_r_scale++; else break;** ** new_TCP_MAXWIN <<=1;** ** new_TCP_MAXWIN |=1;** **}* Please inform me if I am right/wrong. Thanks, Gaurav Goel On Wed, Sep 9, 2009 at 7:59 PM, wrote: > Old Synopsis: TCP window scaling value > New Synopsis: TCP window scaling value calculated incorrectly? > > State-Changed-From-To: feedback->open > State-Changed-By: gavin > State-Changed-When: Wed Sep 9 14:24:24 UTC 2009 > State-Changed-Why: > Over to maintainer(s) for investigation > > > Responsible-Changed-From-To: gavin->freebsd-net > Responsible-Changed-By: gavin > Responsible-Changed-When: Wed Sep 9 14:24:24 UTC 2009 > Responsible-Changed-Why: > Feedback was received, thanks! > > http://www.freebsd.org/cgi/query-pr.cgi?pr=138652 > -- Gaurav Goel --000feae95a4f797c710473393423 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Gavin,

Please find the fix for the problem:

Replac= e
=C2=A0=C2=A0=C2=A0 while (tp->request_r_scale < TCP= _MAX_WINSHIFT &&
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 tp->= ;request_r_scale++;

With
unsigne= d int new_TCP_MAXWIN =3D TCP_MAXWIN;
while (tp->request_r_scale &= lt; TCP_MAX_WINSHIFT)
{
=C2=A0=C2=A0=C2=A0 if(new_TCP_MAXWIN < sb_max)=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 tp->request_r_scale++;
=C2=A0=C2=A0=C2=A0 else
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;
=C2=A0=C2=A0=C2=A0 new_TCP_MAXWIN <<=3D1;=
=C2=A0=C2=A0=C2=A0 new_TCP_MAXWIN |=3D1;
}

Please in= form me if I am right/wrong.

Thanks,
Gaurav Goel

On Wed, Sep 9, 2009 at 7:59 PM, <gavin@freebsd.org> wrote:<= br>
Old Synopsis: TCP= window scaling value
New Synopsis: TCP window scaling value calculated incorrectly?

State-Changed-From-To: feedback->open
State-Changed-By: gavin
State-Changed-When: Wed Sep 9 14:24:24 UTC 2009
State-Changed-Why:
Over to maintainer(s) for investigation


Responsible-Changed-From-To: gavin->freebsd-net
Responsible-Changed-By: gavin
Responsible-Changed-When: Wed Sep 9 14:24:24 UTC 2009
Responsible-Changed-Why:
Feedback was received, thanks!

http://www.freebsd.org/cgi/query-pr.cgi?pr=3D138652



--
Gaurav Goel
--000feae95a4f797c710473393423-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 10 13:46:32 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D501106566B for ; Thu, 10 Sep 2009 13:46:32 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 4B5C88FC08 for ; Thu, 10 Sep 2009 13:46:32 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mljyp-000ICU-7q; Thu, 10 Sep 2009 13:46:31 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id DA4CB29D5D98; Thu, 10 Sep 2009 06:46:30 -0700 (PDT) Date: Thu, 10 Sep 2009 06:46:30 -0700 Message-ID: From: Randy Bush To: "Li, Qing" In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net Subject: Re: forwarding when two rip defaults X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 13:46:32 -0000 > What release are you running ? >> say i run routed and receive rip default from two routers, on the same >> local ether. what is the forwarding? i presume it's not smart enough >> to balance flows. i hope not alternating packets. clue, please? >> >> fwiw, the routers each have full bgp exits. vrrp would force all >> traffic to one. so i am looking at rip or quagga's isisd. the hosts i care about generally run 8/9 randy From owner-freebsd-net@FreeBSD.ORG Thu Sep 10 14:31:13 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D60D31065670 for ; Thu, 10 Sep 2009 14:31:13 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id BCEF48FC0A for ; Thu, 10 Sep 2009 14:31:13 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mlkg4-000INi-O2; Thu, 10 Sep 2009 14:31:12 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 82DAB29D62CB; Thu, 10 Sep 2009 07:31:12 -0700 (PDT) Date: Thu, 10 Sep 2009 07:31:12 -0700 Message-ID: From: Randy Bush To: Stef Walter References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net Subject: Re: forwarding when two rip defaults X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 14:31:13 -0000 >> say i run routed and receive rip default from two routers, on the same >> local ether. what is the forwarding? i presume it's not smart enough >> to balance flows. i hope not alternating packets. clue, please? > Unless you have RADIX_MPATH in your kernel (with a recent FreeBSD, ie: > 8.0) it'll choose one at random aha! that was the clue. docs are a bit thin, still looking. but thank you. randy From owner-freebsd-net@FreeBSD.ORG Thu Sep 10 14:48:01 2009 Return-Path: Delivered-To: net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FEA8106566B for ; Thu, 10 Sep 2009 14:48:01 +0000 (UTC) (envelope-from bynkaay@gmail.com) Received: from mx20.turkticaret.net (mx20.turkticaret.net [89.106.12.90]) by mx1.freebsd.org (Postfix) with ESMTP id B651E8FC2A for ; Thu, 10 Sep 2009 14:48:00 +0000 (UTC) Received: from (unknown [89.106.12.90]) by scm68.turkticaret.net with smtp id 7b0e_0032_0b7ace14_9e28_11de_ab22_001d0965af5f; Thu, 10 Sep 2009 19:36:11 +0300 Received: from gmail.com (unknown [85.103.150.27]) by mx20.turkticaret.net (Postfix) with ESMTPA id B223E39B173 for ; Thu, 10 Sep 2009 17:45:23 +0300 (EEST) From: WWW BYNKAAY COM To: Date: Thu, 10 Sep 2009 17:48:30 +0300 X-Mailer: TOL Mailer MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7Bit Message-Id: <20090910144523.B223E39B173@mx20.turkticaret.net> TURKTICARET.Net-Anti-Spam: Checked! X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 9 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.1.0.8571 : core <3359> : streams <267373> : uri <43816 Cc: Subject: RevoFlash 3 ChipTuning by OBD2 with tuning maps @www.bynkaay.com X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 14:48:01 -0000 Newsletter NKAAY CO., HK LTD w w w . b y n k a a y . c o m - Welcome to BYNKAAY Newsletter RevoFlash 3 ChipTuning by OBD2 with tuning maps. Product Price (in Euro) : 250 REVO is a Car Chip-Turning, specially designed for all kinds of modern cars. Nowadays almost all the manufactures of cars are international groups or enterprises, they have sold their cars to world-widely......more... Engineered Performance for Your Cars REVO WORKS FOR VW AUDI SEAT SKODA DO A CAR ONLY NEED 10-MINUTE ONLY NEED PUT THE SPP CABLE TO THE SOCKET OF DIANGOSTIC IN YOUR CAR AND OPEN THE SOFTWARE REVO is a Car Chip-Turning, specially designed for all kinds of modern cars. Nowadays almost all the manufactures of cars are international groups or enterprises, they have sold their cars to world-widely. Due to the obvious differences of fuel quality, temperature, air pressure, humidity, emission regulations and so on in different countries and areas, the manufacturer must develop his vehicles for a world wide market and must take into account the above different circumstances. DOWNLOAD DETAIL INFO BUY NOW! Shipping by DHL Please visit our web site www.bynkaay.com to see all products. -CONTACTS INSTANT: Mail : info@bynkaay.com MSN :bynkaay@hotmail.com YAHOO :bynkaay@yahoo.com Skype : bynkaay ICQ : 208344566 Support: info@nkaay.com Copyright (C) 2009 All Right Reserved NKAAY CO., HK LIMITED | http://www.nkaay.com Unsubscription : If you do not want to receive this newsletter please Click Here From owner-freebsd-net@FreeBSD.ORG Thu Sep 10 14:56:28 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F25B1065670 for ; Thu, 10 Sep 2009 14:56:28 +0000 (UTC) (envelope-from cjeker@diehard.n-r-g.com) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by mx1.freebsd.org (Postfix) with ESMTP id C54FA8FC22 for ; Thu, 10 Sep 2009 14:56:27 +0000 (UTC) Received: (qmail 20990 invoked by uid 1001); 10 Sep 2009 14:56:26 -0000 Date: Thu, 10 Sep 2009 16:56:26 +0200 From: Claudio Jeker To: freebsd-net@freebsd.org Message-ID: <20090910145626.GE23661@diehard.n-r-g.com> Mail-Followup-To: Claudio Jeker , freebsd-net@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: forwarding when two rip defaults X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 14:56:28 -0000 On Thu, Sep 10, 2009 at 07:31:12AM -0700, Randy Bush wrote: > >> say i run routed and receive rip default from two routers, on the same > >> local ether. what is the forwarding? i presume it's not smart enough > >> to balance flows. i hope not alternating packets. clue, please? > > Unless you have RADIX_MPATH in your kernel (with a recent FreeBSD, ie: > > 8.0) it'll choose one at random > > aha! that was the clue. docs are a bit thin, still looking. but thank > you. > I don't want to disrupt the party but I seriously doubt that routed supports multipath routing. Routed's radix code is unable to handle multipath routes. -- :wq Claudio From owner-freebsd-net@FreeBSD.ORG Thu Sep 10 15:18:51 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5E7810656C1 for ; Thu, 10 Sep 2009 15:18:51 +0000 (UTC) (envelope-from bounces+305227.47622556.587775@icpbounce.com) Received: from smtp4.icpbounce.com (smtp4.icpbounce.com [216.27.93.122]) by mx1.freebsd.org (Postfix) with ESMTP id 850EF8FC0A for ; Thu, 10 Sep 2009 15:18:51 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp4.icpbounce.com (Postfix) with ESMTP id 91E392383D4 for ; Thu, 10 Sep 2009 11:03:14 -0400 (EDT) Date: Thu, 10 Sep 2009 11:03:14 -0400 To: freebsd-net@freebsd.org; From: =?utf-8?Q?Eko_Bilgisayar_ve_=C4=B0leti=C5=9Fim_Hizmetleri_Ltd=2E_=C5=9Eti?= Message-ID: X-Priority: 3 X-Mailer: PHPMailer [version 1.72] Errors-To: bounces+305227.47622556.587775@icpbounce.com X-List-Unsubscribe: X-Unsubscribe-Web: X-ICPINFO: X-Return-Path-Hint: bounces+305227.47622556.587775@icpbounce.com MIME-Version: 1.0 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Turkey Calling You To Visit - The Trade SHOW- In Las Vegas X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 15:18:52 -0000 [http://www.turkeycalling.us] [http://www.turkeycalling.us] [http://www.turkeycalling.us] [http://www.turkeycalling.us/turkey-fam/turkeyfam.htm] Global Access Travel invites you to the Tradeshow in Las Vegas on September 13-15, 2009. Please visit us to get more information about our organization and services at our booth. If you fill the registration form or leave the business card when you visit us at our booth, you might be lucky visitor who is going to win our daily draw prize; Free inspection trip to Turkey. Yasal Uyarı; Bu e-posta, sadece adreste belirtilen kisi veya kurulusun kullanimini hedeflemekte olup,mesajda yer alan bilgiler kisiye ozel ve gizli olabilir, yasalar ya da anlasmalar geregi ücüncü kisiler ile paylasilmasi mümkün olmayabilir.Mesaji alan kisi, mesajin gönderilmek istendigi kisi veya kurulus degilse,bu mesaji yaymak,dagitmak veya kopyalamak yasaktir Mesaj tarafiniza yanlislikla ulasmissa lütfen mesaji geri gönderiniz ve sisteminizden siliniz. Global Access Travel bu mesajin icerigi ile ilgili olarak hicbir hukuksal sorumlulugu kabul etmez Disclaimer This e-mail communication is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and that may not be made public by law or agreement. If the recipient of this message is not the intended recipient or entity, you are hereby notified that any further dissemination, distribution or copying of this information is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete it from your system. The Global Access Traveldoes not accept legal responsibility for the contents of this message. Yasal Uyarı; Bu e-posta, sadece adreste belirtilen kisi veya kurulusun kullanimini hedeflemekte olup,mesajda yer alan bilgiler kisiye ozel ve gizli olabilir, yasalar ya da anlasmalar geregi ücüncü kisiler ile paylasilmasi mümkün olmayabilir.Mesaji alan kisi, mesajin gönderilmek istendigi kisi veya kurulus degilse,bu mesaji yaymak,dagitmak veya kopyalamak yasaktir Mesaj tarafiniza yanlislikla ulasmissa lütfen mesaji geri gönderiniz ve sisteminizden siliniz. Global Access Travel bu mesajin icerigi ile ilgili olarak hicbir hukuksal sorumlulugu kabul etmez Disclaimer This e-mail communication is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and that may not be made public by law or agreement. If the recipient of this message is not the intended recipient or entity, you are hereby notified that any further dissemination, distribution or copying of this information is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete it from your system. The Global Access Traveldoes not accept legal responsibility for the contents of this message. Yasal Uyarı; Bu e-posta, sadece adreste belirtilen kisi veya kurulusun kullanimini hedeflemekte olup,mesajda yer alan bilgiler kisiye ozel ve gizli olabilir, yasalar ya da anlasmalar geregi ücüncü kisiler ile paylasilmasi mümkün olmayabilir.Mesaji alan kisi, mesajin gönderilmek istendigi kisi veya kurulus degilse,bu mesaji yaymak,dagitmak veya kopyalamak yasaktir Mesaj tarafiniza yanlislikla ulasmissa lütfen mesaji geri gönderiniz ve sisteminizden siliniz. Global Access Travel bu mesajin icerigi ile ilgili olarak hicbir hukuksal sorumlulugu kabul etmez Disclaimer This e-mail communication is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and that may not be made public by law or agreement. If the recipient of this message is not the intended recipient or entity, you are hereby notified that any further dissemination, distribution or copying of this information is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete it from your system. The Global Access Traveldoes not accept legal responsibility for the contents of this message. This message was sent by: TURKEY CALLING YOU TO VISIT "THE TRADE SHOW" IN LAS VEGAS, Nüzhetiye Cad, istanbul, Besiktas 34357, Turkey Manage your subscription: http://app.icontact.com/icp/mmail-mprofile.pl?r=47622556&l=82253&s=P83L&m=587775&c=305227 From owner-freebsd-net@FreeBSD.ORG Thu Sep 10 16:07:18 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 022C7106568B for ; Thu, 10 Sep 2009 16:07:18 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id D691A8FC21 for ; Thu, 10 Sep 2009 16:07:17 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlmB2-0000Ms-76; Thu, 10 Sep 2009 16:07:16 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id ED81C29D6C4F; Thu, 10 Sep 2009 09:07:15 -0700 (PDT) Date: Thu, 10 Sep 2009 09:07:15 -0700 Message-ID: From: Randy Bush To: Claudio Jeker In-Reply-To: <20090910145626.GE23661@diehard.n-r-g.com> References: <20090910145626.GE23661@diehard.n-r-g.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: forwarding when two rip defaults X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 16:07:18 -0000 >>>> say i run routed and receive rip default from two routers, on the same >>>> local ether. what is the forwarding? i presume it's not smart enough >>>> to balance flows. i hope not alternating packets. clue, please? >>> Unless you have RADIX_MPATH in your kernel (with a recent FreeBSD, ie: >>> 8.0) it'll choose one at random >> aha! that was the clue. docs are a bit thin, still looking. but thank >> you. > I don't want to disrupt the party but I seriously doubt that routed > supports multipath routing. Routed's radix code is unable to handle > multipath routes. maybe i am confused. but my momma told me that routing != forwarding. i.e. routed will receive two default routes and i hope would install them in the fib, where RADIX_MPATH forwarding would take over. am i wrong about what routed will do? will it choose only one to install in the fib? randy From owner-freebsd-net@FreeBSD.ORG Thu Sep 10 17:19:09 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DC8A106566C; Thu, 10 Sep 2009 17:19:09 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 102A58FC18; Thu, 10 Sep 2009 17:19:08 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n8AHIsxu005141; Thu, 10 Sep 2009 10:18:55 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Sep 2009 10:18:50 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: forwarding when two rip defaults Thread-Index: AcoyMOsiJkzns5e+SA+juorPfUVlBQABsfu3 References: <20090910145626.GE23661@diehard.n-r-g.com> From: "Li, Qing" To: "Randy Bush" , "Claudio Jeker" Cc: freebsd-net@freebsd.org, qingli@freebsd.org Subject: RE: forwarding when two rip defaults X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 17:19:09 -0000 >> I don't want to disrupt the party but I seriously doubt that routed >> supports multipath routing. Routed's radix code is unable to handle >> multipath routes. > > maybe i am confused. but my momma told me that routing !=3D = forwarding. > > i.e. routed will receive two default routes and i hope would install > them in the fib, where RADIX_MPATH forwarding would take over. am i > wrong about what routed will do? will it choose only one to install = in > the fib? > Yes, FIB is a subset of a RIB for the most part, but I think what = Claudio=20 is referring to, is the "radix" code inside the "routed" = implementation,=20 which is incapable of storing multiple routes to the same destination. = That version of the "radix" code is very similar to the original = kernel=20 "radix" code. So although "routed" may be receiving multiple = advertisements about the default routes, but because it's incapable of holding more=20 than 1 such entry in its RIB, how would it be able to install more=20 than 1 entry into the FIB ? When ECMP routes are present, the route selection for forwarding is=20 based on a simple hash key generated from the source and destination=20 IP addresses. =20 Regarding the documentation, you can get some usage text from my = original commit message. I agree more text in a man page form is warranted. At the time I did not receive much input so didn't bother to spend the cycles on more formal writeup.=20 http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D178167 http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D178168 -- Qing From owner-freebsd-net@FreeBSD.ORG Thu Sep 10 21:16:44 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B661A1065694 for ; Thu, 10 Sep 2009 21:16:44 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f195.google.com (mail-qy0-f195.google.com [209.85.221.195]) by mx1.freebsd.org (Postfix) with ESMTP id 65B8B8FC2B for ; Thu, 10 Sep 2009 21:16:44 +0000 (UTC) Received: by qyk33 with SMTP id 33so19682qyk.14 for ; Thu, 10 Sep 2009 14:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:subject :message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=BFCS18T3NYIyvU79XJuW/QvckUWvuAPDWvoyRWawt2c=; b=BkL318s0lWF8H3RrJQ0inmTyl1xnTKC8JIr1eg/xQGimrJ7/OVxAy3Ee1024CvauUW FCjp1WtZzy8u/GKbanXRJQy5V1800faUsWcSnLpTZby4qzKUVgJv8PixIeC/Uk9Q+1XF pNtBR6tTLou+dRfRxtIKt5bXcisDLlp6p4FgU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=XlgP4K5fG4Wfc/+YN9+A9GLzkjrJt7DW6rBPVBi6mtDxdd99yvOTpfrJqXsYLCW1MG DOzQd7q2c0YLFY5g6uhsb1cAHrXZnFD4/hyTaMtyFI1HW92H/b1DIcocxyOjQY+7CSHq hs98uPIOXTEBxfjQR4c4cFEG65a63XiKpm3xc= Received: by 10.224.29.130 with SMTP id q2mr1929731qac.75.1252617403594; Thu, 10 Sep 2009 14:16:43 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 26sm98577qwa.42.2009.09.10.14.16.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 10 Sep 2009 14:16:42 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 10 Sep 2009 14:15:49 -0700 From: Pyun YongHyeon Date: Thu, 10 Sep 2009 14:15:49 -0700 To: freebsd-net@freebsd.org Message-ID: <20090910211549.GK3298@michelle.cdnetworks.com> References: <20090825083857.GA22983@traktor.dnepro.net> <20090825114649.GA11642@traktor.dnepro.net> <20090825130821.GA41669@traktor.dnepro.net> <20090825182553.GD1282@michelle.cdnetworks.com> <20090826093916.GB10790@traktor.dnepro.net> <20090826094856.GC10790@traktor.dnepro.net> <20090901161310.GA37481@traktor.dnepro.net> <20090904212223.GA9950@michelle.cdnetworks.com> <20090908075030.GA6644@traktor.dnepro.net> <20090908213335.GE1520@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090908213335.GE1520@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Subject: Re: D-Link DGE-560SX (Marvell 88E8061-based) doesn't see link X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 21:16:44 -0000 On Tue, Sep 08, 2009 at 02:33:35PM -0700, Pyun YongHyeon wrote: > On Tue, Sep 08, 2009 at 10:50:30AM +0300, Eugene Perevyazko wrote: > > On Fri, Sep 04, 2009 at 02:22:23PM -0700, Pyun YongHyeon wrote: > > > > > > Would you back out previous changes and apply the patch at the > > > following URL? > > > http://people.freebsd.org/~yongari/msk/msk.DGE560.diff2 > > > > > > Note, I have no more access to msk(4) hardwares so it wasn't tested > > > at all except compilation. > > > > > > > Still no success. > > > > mskc0: port 0xd800-0xd8ff mem 0xfeafc000-0xfeafffff irq 16 at device 0.0 on pci1 > > msk0: on mskc0 > > msk0: Ethernet address: 00:21:91:52:4f:09 > > miibus0: on msk0 > > e1000phy0: PHY 0 on miibus0 > > e1000phy0: 1000baseSX, 1000baseSX-FDX, auto > > mskc0: [FILTER] > > > > ifconfig -m msk0 > > msk0: flags=8843 metric 0 mtu 1500 > > options=11a > > capabilities=11a > > ether 00:21:91:52:4f:09 > > inet 10.2.3.1 netmask 0xffffff00 broadcast 10.2.3.255 > > media: Ethernet autoselect (autoselect ) > > status: active > > supported media: > > media autoselect > > media 1000baseSX mediaopt full-duplex > > media 1000baseSX > > media none > > > > Switch shows no link on the port. > > > > # ifconfig msk0 media 1000baseSX mediaopt full-duplex > > # ifconfig msk0 > > msk0: flags=8843 metric 0 mtu 1500 > > options=11a > > ether 00:21:91:52:4f:09 > > inet 10.2.3.1 netmask 0xffffff00 broadcast 10.2.3.255 > > media: Ethernet 1000baseSX (autoselect ) > > status: active > > > > Switch shows no link again. > > > > All dev.msk.0.stats counters are zero even after trying broadcast ping. > > > > I can arrange you root access to the host with this NIC if you have time/wish. > > > > I've sent mail in private. > With the help of original poster, I think I've fixed it. If you're msk(4) user and couldn't send/receive frames on fiber media, please try the patch at the following URL and let me know how it goes. http://people.freebsd.org/~yongari/msk/msk.DGE560.diff4 From owner-freebsd-net@FreeBSD.ORG Thu Sep 10 23:19:09 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4260106566B for ; Thu, 10 Sep 2009 23:19:09 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: from hal.rescomp.berkeley.edu (hal.Rescomp.Berkeley.EDU [169.229.70.150]) by mx1.freebsd.org (Postfix) with ESMTP id 90E8B8FC1E for ; Thu, 10 Sep 2009 23:19:09 +0000 (UTC) Received: by hal.rescomp.berkeley.edu (Postfix, from userid 1225) id AD8F1597D75; Thu, 10 Sep 2009 16:19:08 -0700 (PDT) Date: Thu, 10 Sep 2009 16:19:08 -0700 From: Chris Cowart To: VANHULLEBUS Yvan Message-ID: <20090910231908.GD37291@hal.rescomp.berkeley.edu> Mail-Followup-To: VANHULLEBUS Yvan , freebsd-net@freebsd.org References: <20090904223123.GD16213@hal.rescomp.berkeley.edu> <723505E9-96C6-401C-A844-3D9BA2033795@neville-neil.com> <20090907191001.GA37291@hal.rescomp.berkeley.edu> <54FDC10A-EAE3-4AE2-BF36-2C5F7D141C3A@neville-neil.com> <20090910073739.GB37291@hal.rescomp.berkeley.edu> <20090910081337.GA66528@zeninc.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="3yNHWXBV/QO9xKNm" Content-Disposition: inline In-Reply-To: <20090910081337.GA66528@zeninc.net> Organization: RSSP-IT, UC Berkeley User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net@freebsd.org Subject: Re: IPSEC + long UDP causes reproducible crash [was: Crash in ether_input] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 23:19:09 -0000 --3yNHWXBV/QO9xKNm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable VANHULLEBUS Yvan wrote: > On Thu, Sep 10, 2009 at 12:37:39AM -0700, Chris Cowart wrote: >> I have been using i386 and amd64 virtual machines as well as an amd64 >> physical machine; this problem can be reproduced fairly reliably on all >> of them for 7.0 and 7.1 (and we're pretty sure we saw it in 6.x and >> didn't know what it was at the time). >=20 > I fixed in FreeBSD 7.2+ a bug which looks to be related with your > crashes (kernel panic with big packets), could you please try again > with FreeBSD 7.2 and report us the result ? The problem does indeed seem to be gone with 7.2. Given that any unprivileged user could compile and run such a program on an IPSEC-enabled pre-7.2 box and crash the system, isn't this a local DoS exploit that should be fixed in the supported security branches (including 7.1)? --=20 Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley --3yNHWXBV/QO9xKNm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iQIcBAEBAwAGBQJKqYlsAAoJEC8b9sM8ejXtJxIP/RwdxU/KpDf39Gzt+cYwfY7a FAkG8Us/qWKdhhoERRnHu0MQsFhOCAWSDDcczBDm60B5urbhbec55uROspt7Jrzc cNIcAp9CBGzVwBImbmAgllOIIkLIQZK7HInTCCl0ekjkYYvmyw42b9LSSo4myyQu M/yFjb5HAVjhy2WzcZvrNoZFMOCM9tPHEpx1p4NYybS1tRk8eUvnIi3rkxPTBMFb SjGo7xm6fYBDz8skGLRvzEDJNJf66OqSJwot4Hvu6la73iirGgPnw8kX0LzTSRxb 1btd91keBLx3cnhQJxGD4F7J554ZGAaTXIHYYfc4gVKFcoiC7elZzrsSzaJ0ZA5y zxdyYoJbsV18N9TOMNwkw5kglPzsmdMxYBI4vdE61QrYgLe7vX/2y5hdUmWs7QWk 5NVXoHwkq7WetjxGSzRkeXXkqeXVwwgl2MVfBj909BaMXWQrRy2y8j3FxSq6JLZ2 QJm6cIlsQHMgMUloUlp8LgN1duuzREqfVpXZEeUyFRIVvts/a43wqxfiiOE6Lxqh JkhNi8MeLJoc1BSBsTVmZ29Opa9hGbp0wXEpDoXdrN6TsE1XAb1+zHxJeuZHFi6u pnaWfyYZSmqfctDnmAo9vJGZxtYcvByZYsrpGmsSL4MiThtcpL7R7LibR4BrnAAX Bafw/FPSLr91kYkiwHbc =32dj -----END PGP SIGNATURE----- --3yNHWXBV/QO9xKNm-- From owner-freebsd-net@FreeBSD.ORG Fri Sep 11 11:03:51 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFBF81065676; Fri, 11 Sep 2009 11:03:51 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A6B3F8FC19; Fri, 11 Sep 2009 11:03:51 +0000 (UTC) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8BB3pVW073641; Fri, 11 Sep 2009 11:03:51 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8BB3pU5073637; Fri, 11 Sep 2009 11:03:51 GMT (envelope-from gavin) Date: Fri, 11 Sep 2009 11:03:51 GMT Message-Id: <200909111103.n8BB3pU5073637@freefall.freebsd.org> To: gavin@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: amd64/138688: [rum] possibly broken on 8 Beta 4 amd64: able to wpa authenticate + obtain dhclient address, no communication though. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 11:03:51 -0000 Old Synopsis: rum possibly broken on 8 Beta 4 amd64: Linksys WUSB54GC v1 device appears as rum, clonable to wlan0, able to wpa authenticate + obtain dhclient address, no communication though. New Synopsis: [rum] possibly broken on 8 Beta 4 amd64: able to wpa authenticate + obtain dhclient address, no communication though. Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Fri Sep 11 11:02:12 UTC 2009 Responsible-Changed-Why: Over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=138688 From owner-freebsd-net@FreeBSD.ORG Fri Sep 11 11:46:39 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE9551065670 for ; Fri, 11 Sep 2009 11:46:39 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 73E798FC0C for ; Fri, 11 Sep 2009 11:46:39 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n8BBh7wm095653; Fri, 11 Sep 2009 07:43:07 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200909111143.n8BBh7wm095653@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 11 Sep 2009 07:46:39 -0400 To: Barney Cordoba From: Mike Tancsa In-Reply-To: <200909091525.n89FPUv3080170@lava.sentex.ca> References: <200909091352.n89DqQDx079631@lava.sentex.ca> <538232.7388.qm@web63901.mail.re1.yahoo.com> <200909091513.n89FDgdf080109@lava.sentex.ca> <200909091525.n89FPUv3080170@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: em driver input errors X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 11:46:39 -0000 At 11:28 AM 9/9/2009, Mike Tancsa wrote: >At 11:17 AM 9/9/2009, Mike Tancsa wrote: >>The board is an intel >> >>http://www.intel.com/support/motherboards/server/s3000ah/ >> >>Not sure if its wired as PCI-X or just a 32bit bus. I am just >>popping in an em pcie nic to see if that makes a difference. I >>have an igb as well as bge I can try later. > >OK, now there is > >em0@pci0:5:0:0: class=0x020000 card=0xa01f8086 chip=0x10d38086 >rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled > > OK, much better. Two nights in a row without errors, and Friday AM has a lot of level0 dumps. Perhaps as you speculated, the onboard NICs were wired to a slower bus... The pcie 1x hasnt shown any errors yet. Sep 11 00:01:00 backup3 kernel: em0: Excessive collisions = 0 Sep 11 00:01:00 backup3 kernel: em0: Sequence errors = 0 Sep 11 00:01:00 backup3 kernel: em0: Defer count = 0 Sep 11 00:01:00 backup3 kernel: em0: Missed Packets = 0 Sep 11 00:01:00 backup3 kernel: em0: Receive No Buffers = 0 Sep 11 00:01:00 backup3 kernel: em0: Receive Length Errors = 0 Sep 11 00:01:00 backup3 kernel: em0: Receive errors = 0 Sep 11 00:01:00 backup3 kernel: em0: Crc errors = 0 Sep 11 00:01:00 backup3 kernel: em0: Alignment errors = 0 Sep 11 00:01:00 backup3 kernel: em0: Collision/Carrier extension errors = 0 Sep 11 00:01:00 backup3 kernel: em0: RX overruns = 0 Sep 11 00:01:00 backup3 kernel: em0: watchdog timeouts = 0 Sep 11 00:01:00 backup3 kernel: em0: RX MSIX IRQ = 50004846 TX MSIX IRQ = 40678847 LINK MSIX IRQ = 1 Sep 11 00:01:00 backup3 kernel: em0: XON Rcvd = 0 Sep 11 00:01:00 backup3 kernel: em0: XON Xmtd = 0 Sep 11 00:01:00 backup3 kernel: em0: XOFF Rcvd = 0 Sep 11 00:01:00 backup3 kernel: em0: XOFF Xmtd = 0 Sep 11 00:01:00 backup3 kernel: em0: Good Packets Rcvd = 73064815 Sep 11 00:01:00 backup3 kernel: em0: Good Packets Xmtd = 52479296 Sep 11 00:01:00 backup3 kernel: em0: TSO Contexts Xmtd = 0 Sep 11 00:01:00 backup3 kernel: em0: TSO Contexts Failed = 0 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll em0 1500 00:1b:21:3f:62:72 193269942 0 133269168 0 0 em0 1500 10.45.129.132 10.45.129.133 0 - 0 - - em1 1500 00:15:17:57:31:8a 0 0 0 0 0 em1 1500 10.45.129.128 10.45.129.129 0 - 0 - - em2* 1500 00:15:17:57:31:8b 0 0 0 0 0 ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-net@FreeBSD.ORG Fri Sep 11 12:03:02 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58A93106568F for ; Fri, 11 Sep 2009 12:03:02 +0000 (UTC) (envelope-from xylnao@gmail.com) Received: from mail-qy0-f195.google.com (mail-qy0-f195.google.com [209.85.221.195]) by mx1.freebsd.org (Postfix) with ESMTP id 18E6E8FC17 for ; Fri, 11 Sep 2009 12:03:01 +0000 (UTC) Received: by qyk33 with SMTP id 33so363889qyk.14 for ; Fri, 11 Sep 2009 05:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=cB5JnEEdMU4v8P+KQjG0ub/NeBO810MSBzrGpp+ebEg=; b=pO3R+oE92VRGRZ9+jipiH9Kjsu/nhEkTALp07v2R7c/9aeZnvvcyrY1S8y0pBTpODv a5YQrMEMz/bPW+L0SBac1VXOyWZDXkmJilbD6SFmGvcg07qL/bsuP3FiTgan2NQG+xyM Yy7UU9Q3N+vVCYSORuKRyxzf+gUvG3ry73xMk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=azLNx5bV4bH3pgR8G6Faj+rGzbgbO1riPGZJkFpHbP6MGNF4D73flXjRCzGnHQAvxa Gv9Cf9n0d5PRb5hGuVm5oHnITjVlLciTfDTbVi2ITzA/Izh0OYXhWf4gX8x0hygeKJXy B3cH9rJF56hC53qiclRHllz4InyVRy/6rhIco= MIME-Version: 1.0 Sender: xylnao@gmail.com Received: by 10.224.111.140 with SMTP id s12mr1550623qap.128.1252669284789; Fri, 11 Sep 2009 04:41:24 -0700 (PDT) Date: Fri, 11 Sep 2009 20:41:24 +0900 X-Google-Sender-Auth: 63cd25449e122bc8 Message-ID: <2da2ec620909110441o2575dcd4tc8498ecff59caf03@mail.gmail.com> From: Naoki Hamada To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: FIB for RELENG_6? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 12:03:02 -0000 Hello, guys! Is there a patch set of FIB for RELENG_6 (now 6.4-STABLE)? If there is any, I want apply it to my multi-homed server in preparation for a forthcoming IP address transition process and mitigate its complication. I tried a FIB enabled 7.2 machine with recent changes and found it perfectly fits my purpose. Regards, Naoki Hamada nao@tom-yam.or.jp From owner-freebsd-net@FreeBSD.ORG Fri Sep 11 15:29:35 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 357A110656C3 for ; Fri, 11 Sep 2009 15:29:35 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outZ.internet-mail-service.net (outz.internet-mail-service.net [216.240.47.249]) by mx1.freebsd.org (Postfix) with ESMTP id 1FB018FC21 for ; Fri, 11 Sep 2009 15:29:34 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 96E74A300F; Fri, 11 Sep 2009 08:29:34 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 620612D601D; Fri, 11 Sep 2009 08:29:34 -0700 (PDT) Message-ID: <4AAA6CDC.2060406@elischer.org> Date: Fri, 11 Sep 2009 08:29:32 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Naoki Hamada References: <2da2ec620909110441o2575dcd4tc8498ecff59caf03@mail.gmail.com> In-Reply-To: <2da2ec620909110441o2575dcd4tc8498ecff59caf03@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: FIB for RELENG_6? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 15:29:35 -0000 Naoki Hamada wrote: > Hello, guys! > > Is there a patch set of FIB for RELENG_6 (now 6.4-STABLE)? > If there is any, I want apply it to my multi-homed server in preparation for > a forthcoming IP address transition process and mitigate its complication. > I tried a FIB enabled 7.2 machine with recent changes and found it perfectly > fits my purpose. > > Regards, > > Naoki Hamada > nao@tom-yam.or.jp > _______________________________________________ > 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" multi fib support in 6 was not released from Ironport. if you have 7 why do you want to stay with 6? From owner-freebsd-net@FreeBSD.ORG Fri Sep 11 16:38:31 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5917B106568F for ; Fri, 11 Sep 2009 16:38:31 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-yx0-f193.google.com (mail-yx0-f193.google.com [209.85.210.193]) by mx1.freebsd.org (Postfix) with ESMTP id 0FBC38FC08 for ; Fri, 11 Sep 2009 16:38:30 +0000 (UTC) Received: by yxe31 with SMTP id 31so1593989yxe.29 for ; Fri, 11 Sep 2009 09:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=CqdRqcyQ2hWqHvpDKWRbxUpMoQKXI+fpmPYpaOLOsDs=; b=fSXAY3gAVdp+icAl4AhpGEfzDm34enrlWlh8XvFCIqdvcJk0i9M2/fFBAIoVcju5cB ifUv8J+cyv3+F9GeOKiqsa2zNmTH3EkpTR/3/WGqA62YMN6N6mIRUE2Ep8lXlPukSdAX xmAdM9EJBEvodouwZWvtXxjwnL+qVXJioZPkY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OrE312WG3huHi0EG51a5OHteonNW8KJtnkhgzNvpXwW72+zbv0LOUgIvlsy0HPeDfF C0NcCQLl/DoSY5O1R5bskSpfP6hTu/OmVrLDSdE6cwSebbWjKvDwcsaInMbHNrXeqPVU dCcjc+xDFsjR97ukyLAY1MhShxs1bdYGe6bqg= MIME-Version: 1.0 Received: by 10.101.7.25 with SMTP id k25mr3396891ani.192.1252687108826; Fri, 11 Sep 2009 09:38:28 -0700 (PDT) In-Reply-To: <200909111143.n8BBh7wm095653@lava.sentex.ca> References: <200909091352.n89DqQDx079631@lava.sentex.ca> <538232.7388.qm@web63901.mail.re1.yahoo.com> <200909091513.n89FDgdf080109@lava.sentex.ca> <200909091525.n89FPUv3080170@lava.sentex.ca> <200909111143.n8BBh7wm095653@lava.sentex.ca> Date: Fri, 11 Sep 2009 09:38:28 -0700 Message-ID: <2a41acea0909110938l2348e35ah11bd1876fbe22dd3@mail.gmail.com> From: Jack Vogel To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Barney Cordoba , freebsd-net@freebsd.org Subject: Re: em driver input errors X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 16:38:31 -0000 Glad to hear this. Jack On Fri, Sep 11, 2009 at 4:46 AM, Mike Tancsa wrote: > At 11:28 AM 9/9/2009, Mike Tancsa wrote: > >> At 11:17 AM 9/9/2009, Mike Tancsa wrote: >> >>> The board is an intel >>> >>> http://www.intel.com/support/motherboards/server/s3000ah/ >>> >>> Not sure if its wired as PCI-X or just a 32bit bus. I am just popping in >>> an em pcie nic to see if that makes a difference. I have an igb as well as >>> bge I can try later. >>> >> >> OK, now there is >> >> em0@pci0:5:0:0: class=0x020000 card=0xa01f8086 chip=0x10d38086 rev=0x00 >> hdr=0x00 >> vendor = 'Intel Corporation' >> class = network >> subclass = ethernet >> cap 01[c8] = powerspec 2 supports D0 D3 current D0 >> cap 05[d0] = MSI supports 1 message, 64 bit >> cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) >> cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled >> >> >> > > OK, much better. Two nights in a row without errors, and Friday AM has a > lot of level0 dumps. Perhaps as you speculated, the onboard NICs were wired > to a slower bus... The pcie 1x hasnt shown any errors yet. > > Sep 11 00:01:00 backup3 kernel: em0: Excessive collisions = 0 > Sep 11 00:01:00 backup3 kernel: em0: Sequence errors = 0 > Sep 11 00:01:00 backup3 kernel: em0: Defer count = 0 > Sep 11 00:01:00 backup3 kernel: em0: Missed Packets = 0 > Sep 11 00:01:00 backup3 kernel: em0: Receive No Buffers = 0 > Sep 11 00:01:00 backup3 kernel: em0: Receive Length Errors = 0 > Sep 11 00:01:00 backup3 kernel: em0: Receive errors = 0 > Sep 11 00:01:00 backup3 kernel: em0: Crc errors = 0 > Sep 11 00:01:00 backup3 kernel: em0: Alignment errors = 0 > Sep 11 00:01:00 backup3 kernel: em0: Collision/Carrier extension errors = 0 > Sep 11 00:01:00 backup3 kernel: em0: RX overruns = 0 > Sep 11 00:01:00 backup3 kernel: em0: watchdog timeouts = 0 > Sep 11 00:01:00 backup3 kernel: em0: RX MSIX IRQ = 50004846 TX MSIX IRQ = > 40678847 LINK MSIX IRQ = 1 > Sep 11 00:01:00 backup3 kernel: em0: XON Rcvd = 0 > Sep 11 00:01:00 backup3 kernel: em0: XON Xmtd = 0 > Sep 11 00:01:00 backup3 kernel: em0: XOFF Rcvd = 0 > Sep 11 00:01:00 backup3 kernel: em0: XOFF Xmtd = 0 > Sep 11 00:01:00 backup3 kernel: em0: Good Packets Rcvd = 73064815 > Sep 11 00:01:00 backup3 kernel: em0: Good Packets Xmtd = 52479296 > Sep 11 00:01:00 backup3 kernel: em0: TSO Contexts Xmtd = 0 > Sep 11 00:01:00 backup3 kernel: em0: TSO Contexts Failed = 0 > > > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs > Coll > em0 1500 00:1b:21:3f:62:72 193269942 0 133269168 0 > 0 > em0 1500 10.45.129.132 10.45.129.133 0 - 0 - > - > em1 1500 00:15:17:57:31:8a 0 0 0 0 > 0 > em1 1500 10.45.129.128 10.45.129.129 0 - 0 - > - > em2* 1500 00:15:17:57:31:8b 0 0 0 0 > 0 > > > ---Mike > > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Sep 11 21:50:10 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 713DD1065692 for ; Fri, 11 Sep 2009 21:50:10 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail15.syd.optusnet.com.au (mail15.syd.optusnet.com.au [211.29.132.196]) by mx1.freebsd.org (Postfix) with ESMTP id 0745E8FC19 for ; Fri, 11 Sep 2009 21:50:09 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-250-30.belrs3.nsw.optusnet.com.au [122.106.250.30]) by mail15.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n8BLo7Eo003331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 12 Sep 2009 07:50:08 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n8BLo6hD055120 for ; Sat, 12 Sep 2009 07:50:06 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n8BLo668055119 for freebsd-net@freebsd.org; Sat, 12 Sep 2009 07:50:06 +1000 (EST) (envelope-from peter) Date: Sat, 12 Sep 2009 07:50:06 +1000 From: Peter Jeremy To: freebsd-net@freebsd.org Message-ID: <20090911215006.GA31432@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Subject: New tcpdump in 8.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 21:50:10 -0000 --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [Please excuse long lines] Who has used tcpdump on FreeBSD 8.x and likes it? Is it just me or is it now far harder to investigate network problems using it? Prior to 8.x, the default output includes SEQ number ranges for any TCP packets with data, so a 'tcpdump -n' looks like the following and it's immediately obvious that there's 2920 bytes of data missing: 08:48:32.137596 IP 134.159.99.234.60834 > 122.106.250.30.2202: . 221537:222= 997(1460) ack 2609 win 65535 08:48:32.138492 IP 134.159.99.234.60834 > 122.106.250.30.2202: . 222997:224= 457(1460) ack 2609 win 65535 08:48:32.139601 IP 122.106.250.30.2202 > 134.159.99.234.60834: . ack 224457= win 64240 08:48:32.145623 IP 134.159.99.234.60834 > 122.106.250.30.2202: . 227377:228= 837(1460) ack 2609 win 65535 08:48:32.146703 IP 122.106.250.30.2202 > 134.159.99.234.60834: . ack 224457= win 65535 The same output on 8.x looks like the following. Whilst the last ACK packet looks anomolous, there's no useful information to analyse further. 08:48:32.137596 IP 134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], a= ck 2609, win 65535, length 1460 08:48:32.138492 IP 134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], a= ck 2609, win 65535, length 1460 08:48:32.139601 IP 122.106.250.30.2202 > 134.159.99.234.60834: Flags [.], a= ck 224457, win 64240, length 0 08:48:32.145623 IP 134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], a= ck 2609, win 65535, length 1460 08:48:32.146703 IP 122.106.250.30.2202 > 134.159.99.234.60834: Flags [.], a= ck 224457, win 65535, length 0 In order to see the SEQ numbers (which are essential to make sense of the capture), you need to add '-vv' - which turns the output into: 08:48:32.137596 IP (tos 0x0, ttl 52, id 32485, offset 0, flags [DF], proto = TCP (6), length 1500) 134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], seq 221537:22299= 7, ack 2609, win 65535, length 1460 08:48:32.138492 IP (tos 0x0, ttl 52, id 32486, offset 0, flags [DF], proto = TCP (6), length 1500) 134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], seq 222997:22445= 7, ack 2609, win 65535, length 1460 08:48:32.139601 IP (tos 0x8, ttl 63, id 46554, offset 0, flags [DF], proto = TCP (6), length 40) 122.106.250.30.2202 > 134.159.99.234.60834: Flags [.], cksum 0xe759 (co= rrect), seq 2609, ack 224457, win 64240, length 0 08:48:32.145623 IP (tos 0x0, ttl 52, id 32489, offset 0, flags [DF], proto = TCP (6), length 1500) 134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], seq 227377:22883= 7, ack 2609, win 65535, length 1460 08:48:32.146703 IP (tos 0x8, ttl 63, id 46555, offset 0, flags [DF], proto = TCP (6), length 40) 122.106.250.30.2202 > 134.159.99.234.60834: Flags [.], cksum 0xe24a (co= rrect), seq 2609, ack 224457, win 65535, length 0 Whilst it's now possible to work out that there's 2920 bytes of data missing, this information is mixed up in so much other extraneous information that the dump is almost useless. In particular, it's no longer possible to scan a tcpdump output and easily see packet loss or out-of-order delivery. --=20 Peter Jeremy --pf9I7BMVVzbSWLtt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkqqxg4ACgkQ/opHv/APuIdAngCeMjWwA66RYx5JVMyUI6DxNT+C jo0An02IM9wDixakm6pq1grALUx8azAM =q1Ex -----END PGP SIGNATURE----- --pf9I7BMVVzbSWLtt-- From owner-freebsd-net@FreeBSD.ORG Fri Sep 11 22:12:08 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EDCB106566B for ; Fri, 11 Sep 2009 22:12:08 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id E45C28FC0C for ; Fri, 11 Sep 2009 22:12:07 +0000 (UTC) Received: (qmail 27622 invoked from network); 11 Sep 2009 22:12:05 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 11 Sep 2009 22:12:05 -0000 Date: Sat, 12 Sep 2009 00:12:05 +0200 (CEST) Message-Id: <20090912.001205.74713342.sthaug@nethelp.no> To: peterjeremy@acm.org From: sthaug@nethelp.no In-Reply-To: <20090911215006.GA31432@server.vk2pj.dyndns.org> References: <20090911215006.GA31432@server.vk2pj.dyndns.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: New tcpdump in 8.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 22:12:08 -0000 > Who has used tcpdump on FreeBSD 8.x and likes it? Is it just me or is > it now far harder to investigate network problems using it? > > Prior to 8.x, the default output includes SEQ number ranges for any > TCP packets with data, so a 'tcpdump -n' looks like the following and > it's immediately obvious that there's 2920 bytes of data missing: ... > The same output on 8.x looks like the following. Whilst the last ACK > packet looks anomolous, there's no useful information to analyse further. I agree that this change is rather unhelpful. However, this is the default for tcpdump 4.0.0. Thus the choice is between the old tcpdump, the new one (with bugfixes and more protocol decoding), or possibly the new one plus local patches. Not an easy choice, is it? The place to discuss this change is probably the tcpdump-workers list, tcpdump-workers@lists.tcpdump.org Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Fri Sep 11 22:56:49 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD17F1065679 for ; Fri, 11 Sep 2009 22:56:49 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from k7.mavetju.org (ppp113-58.static.internode.on.net [150.101.113.58]) by mx1.freebsd.org (Postfix) with ESMTP id B4DAD8FC2B for ; Fri, 11 Sep 2009 22:56:47 +0000 (UTC) Received: by k7.mavetju.org (Postfix, from userid 1001) id BB071450DA; Sat, 12 Sep 2009 08:37:02 +1000 (EST) Date: Sat, 12 Sep 2009 08:37:02 +1000 From: Edwin Groothuis To: sthaug@nethelp.no Message-ID: <20090911223702.GA4562@mavetju.org> References: <20090911215006.GA31432@server.vk2pj.dyndns.org> <20090912.001205.74713342.sthaug@nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090912.001205.74713342.sthaug@nethelp.no> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, peterjeremy@acm.org Subject: Re: New tcpdump in 8.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 22:56:49 -0000 On Sat, Sep 12, 2009 at 12:12:05AM +0200, sthaug@nethelp.no wrote: > > Who has used tcpdump on FreeBSD 8.x and likes it? Is it just me or is > > it now far harder to investigate network problems using it? > > > > Prior to 8.x, the default output includes SEQ number ranges for any > > TCP packets with data, so a 'tcpdump -n' looks like the following and > > it's immediately obvious that there's 2920 bytes of data missing: > ... > > The same output on 8.x looks like the following. Whilst the last ACK > > packet looks anomolous, there's no useful information to analyse further. > > I agree that this change is rather unhelpful. However, this is the > default for tcpdump 4.0.0. Thus the choice is between the old tcpdump, > the new one (with bugfixes and more protocol decoding), or possibly > the new one plus local patches. Not an easy choice, is it? While I agree with the original poster that you are missing some data, I also agree that talking to the "vendors" of tcpdump is a better way. Peter, if you are keen on it, submit a port (net/tcpdump39) which gives you the old functionality and alert me about it. Edwin, who at least now knows why tcpdump on 8.0B3 did look so trange. -- Edwin Groothuis Website: http://www.mavetju.org/ edwin@mavetju.org Weblog: http://www.mavetju.org/weblog/ From owner-freebsd-net@FreeBSD.ORG Sat Sep 12 00:53:39 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 230CF106566C; Sat, 12 Sep 2009 00:53:39 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EE30F8FC16; Sat, 12 Sep 2009 00:53:38 +0000 (UTC) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8C0rcXn005361; Sat, 12 Sep 2009 00:53:38 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8C0rcbZ005357; Sat, 12 Sep 2009 00:53:38 GMT (envelope-from linimon) Date: Sat, 12 Sep 2009 00:53:38 GMT Message-Id: <200909120053.n8C0rcbZ005357@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/138739: [wpi] wpi(4) does not work very well under 8.0-BETA4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 00:53:39 -0000 Old Synopsis: wpi(4) does not work very well under 8.0-BETA4 New Synopsis: [wpi] wpi(4) does not work very well under 8.0-BETA4 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Sep 12 00:53:04 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138739 From owner-freebsd-net@FreeBSD.ORG Sat Sep 12 03:37:29 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AFD21065670; Sat, 12 Sep 2009 03:37:29 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 513F18FC13; Sat, 12 Sep 2009 03:37:29 +0000 (UTC) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8C3bSuP066607; Sat, 12 Sep 2009 03:37:28 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8C3bSRU066603; Sat, 12 Sep 2009 03:37:28 GMT (envelope-from linimon) Date: Sat, 12 Sep 2009 03:37:28 GMT Message-Id: <200909120337.n8C3bSRU066603@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/138689: [netinet] patch] Multicast: IP_DROP_MEMBERSHIP should return EADDRNOTAVAIL for invalid address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 03:37:29 -0000 Old Synopsis: [patch] Multicast: IP_DROP_MEMBERSHIP should return EADDRNOTAVAIL for invalid address New Synopsis: [netinet] patch] Multicast: IP_DROP_MEMBERSHIP should return EADDRNOTAVAIL for invalid address Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Sep 12 03:36:23 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138689 From owner-freebsd-net@FreeBSD.ORG Sat Sep 12 03:38:17 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B389C1065676; Sat, 12 Sep 2009 03:38:17 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8A5818FC22; Sat, 12 Sep 2009 03:38:17 +0000 (UTC) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8C3cHFC066691; Sat, 12 Sep 2009 03:38:17 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8C3cHj3066687; Sat, 12 Sep 2009 03:38:17 GMT (envelope-from linimon) Date: Sat, 12 Sep 2009 03:38:17 GMT Message-Id: <200909120338.n8C3cHj3066687@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/138690: [netinet] [patch] multicast: uninited memory used in filter at IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 03:38:17 -0000 Old Synopsis: Multicast: uninited memory used in filter at IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP New Synopsis: [netinet] [patch] multicast: uninited memory used in filter at IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Sep 12 03:37:52 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138690 From owner-freebsd-net@FreeBSD.ORG Sat Sep 12 03:38:59 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDCD11065693; Sat, 12 Sep 2009 03:38:59 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 94E0B8FC12; Sat, 12 Sep 2009 03:38:59 +0000 (UTC) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8C3cx63066774; Sat, 12 Sep 2009 03:38:59 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8C3cxeu066770; Sat, 12 Sep 2009 03:38:59 GMT (envelope-from linimon) Date: Sat, 12 Sep 2009 03:38:59 GMT Message-Id: <200909120338.n8C3cxeu066770@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/137164: [netinet] [patch] assert panic imo_match_source() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 03:38:59 -0000 Old Synopsis: [socket] [panic] assert panic imo_match_source() New Synopsis: [netinet] [patch] assert panic imo_match_source() Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Sep 12 03:38:26 UTC 2009 Responsible-Changed-Why: A patch is now included. Reassign to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=137164 From owner-freebsd-net@FreeBSD.ORG Sat Sep 12 03:39:28 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 126CD106571E; Sat, 12 Sep 2009 03:39:28 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DDFA58FC24; Sat, 12 Sep 2009 03:39:27 +0000 (UTC) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8C3dRSC066855; Sat, 12 Sep 2009 03:39:27 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8C3dRPA066851; Sat, 12 Sep 2009 03:39:27 GMT (envelope-from linimon) Date: Sat, 12 Sep 2009 03:39:27 GMT Message-Id: <200909120339.n8C3dRPA066851@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/138691: [netinet] [patch] Multicast: Keep membership and filters in sync X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 03:39:28 -0000 Old Synopsis: Multicast: Keep membership and filters in sync New Synopsis: [netinet] [patch] Multicast: Keep membership and filters in sync Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Sep 12 03:39:08 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138691 From owner-freebsd-net@FreeBSD.ORG Sat Sep 12 03:45:36 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D398E1065679; Sat, 12 Sep 2009 03:45:36 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A98348FC08; Sat, 12 Sep 2009 03:45:36 +0000 (UTC) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8C3jaLR076310; Sat, 12 Sep 2009 03:45:36 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8C3jaWG076306; Sat, 12 Sep 2009 03:45:36 GMT (envelope-from linimon) Date: Sat, 12 Sep 2009 03:45:36 GMT Message-Id: <200909120345.n8C3jaWG076306@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/138694: [bge] FreeBSD 6.3 release does not recognize Broadcom BCM5709C card on IBM X3550 M2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 03:45:36 -0000 Synopsis: [bge] FreeBSD 6.3 release does not recognize Broadcom BCM5709C card on IBM X3550 M2 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Sep 12 03:45:23 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138694 From owner-freebsd-net@FreeBSD.ORG Sat Sep 12 09:07:56 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D25BF1065670 for ; Sat, 12 Sep 2009 09:07:56 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from mx73.mail.ru (mx73.mail.ru [94.100.176.87]) by mx1.freebsd.org (Postfix) with ESMTP id 8F57B8FC15 for ; Sat, 12 Sep 2009 09:07:56 +0000 (UTC) Received: from mx48.mail.ru (mx48.mail.ru [94.100.176.62]) by mx73.mail.ru (mPOP.Fallback_MX) with ESMTP id D79F6650207 for ; Sat, 12 Sep 2009 11:27:20 +0400 (MSD) Received: from [217.25.27.27] (port=63228 helo=[217.25.27.27]) by mx48.mail.ru with asmtp id 1MmN0w-0002H2-00 for freebsd-net@freebsd.org; Sat, 12 Sep 2009 11:27:18 +0400 Message-ID: <4AAB4D56.30207@mail.ru> Date: Sat, 12 Sep 2009 12:27:18 +0500 From: rihad User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Subject: [POLLING] strange interrupt/system load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "rihad@mail.ru >> rihad" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 09:07:56 -0000 The box experiences ~230 mbit/s traffic flow through it. I've doubled some sysctls after reading polling(4): kern.polling.each_burst=10 # was: 5 kern.polling.burst_max=350 # was: 150 FreeBSD 7.2-RELEASE-p3 amd64 HZ=1000 Now for the fun part. With kern.polling.idle_poll = 1 top shows: CPU: 0.0% user, 0.0% nice, 26.9% system, 3.1% interrupt, 70.0% idle ~8000 interrupts/s total according to systat -vmstat: 1999 cpu0: time 2000 cpu1: time 1999 cpu2: time 1999 cpu3: time With kern.polling.idle_poll = 0 top shows: CPU: 0.0% user, 0.0% nice, 0.0% system, 13.9% interrupt, 86.0% idle Still the same ~8000 clock interrupts/s. Under both scenarios polling is enabled on both em0 and em1 through ifconfig. 1) Why is the interrupt load relatively high with polling enabled? 2) How come 13.9% interrupts are not also in the first scenario if their total rate is the same (~8000)? Thanks. From owner-freebsd-net@FreeBSD.ORG Sat Sep 12 10:59:32 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62B661065670 for ; Sat, 12 Sep 2009 10:59:32 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 030228FC0C for ; Sat, 12 Sep 2009 10:59:31 +0000 (UTC) Received: from besplex.bde.org (c122-107-125-150.carlnfd1.nsw.optusnet.com.au [122.107.125.150]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n8CAxS1K019944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Sep 2009 20:59:29 +1000 Date: Sat, 12 Sep 2009 20:59:28 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: rihad In-Reply-To: <4AAB4D56.30207@mail.ru> Message-ID: <20090912202529.X1569@besplex.bde.org> References: <4AAB4D56.30207@mail.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org Subject: Re: [POLLING] strange interrupt/system load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 10:59:32 -0000 On Sat, 12 Sep 2009, rihad wrote: > The box experiences ~230 mbit/s traffic flow through it. I've doubled some > sysctls after reading polling(4): > kern.polling.each_burst=10 # was: 5 > kern.polling.burst_max=350 # was: 150 > > FreeBSD 7.2-RELEASE-p3 amd64 > HZ=1000 How much better does it work without POLLING? > Now for the fun part. > > With kern.polling.idle_poll = 1 top shows: > CPU: 0.0% user, 0.0% nice, 26.9% system, 3.1% interrupt, 70.0% idle > ~8000 interrupts/s total according to systat -vmstat: > 1999 cpu0: time > 2000 cpu1: time > 1999 cpu2: time > 1999 cpu3: time I think the poll thread is still single-threaded. It takes all the available time from 1 idle CPU (possibly not always the same one), and thus makes an average of 1 CPU 100% not-really-idle, and thus ensures a CPU utlization of at lease 25% with 4 CPUs. Here you have slightly more than 25%. > With kern.polling.idle_poll = 0 top shows: > CPU: 0.0% user, 0.0% nice, 0.0% system, 13.9% interrupt, 86.0% idle > Still the same ~8000 clock interrupts/s. The actual overhead seems to be 14% of 4 CPUs or 56% of 1 CPU. Polling in idle is mostly wasting 44% of 1 CPU. (The wastage is not quite complete since polling may improve latency). > Under both scenarios polling is enabled on both em0 and em1 through ifconfig. POLLING is especially useless for em since its hardware has better interrupt moderation than most NICs. In non-old versions of FreeBSD em should be configured so as to not use it, and then em will use fast interrupts and threads, a method that has a chance of working much better than both POLLING and normal interrupts (but I haven't actually seen it working much better). However, em's configuration of this is bad: you have to not configure POLLING, and this prevents use of polling on NICs that might actually benefit from it. > 1) Why is the interrupt load relatively high with polling enabled? 3.1% is already high. Probably there are a lot of software interrupts (netisrs). > 2) How come 13.9% interrupts are not also in the first scenario if their > total rate is the same (~8000)? Possibly there are even more software interrupts, due to the polling thread running into itself. Look at %CPU for each individual thread. Without polling, but with non-fast em interrupts, there will be lots of em interrupts, and the interrupt overhead will be more evenly distributed between the em interrupt thread and swi thread(s), so it is easier to see where the cycles are going (still quite hard, since lots of the cycles are for cache misses and a badly-behaved thread or hardware may cause the slowness to appear to be in a different thread due to it pushing the cache misses there...). Without polling, but with fast em interrupts and em non-interrupt threads, the interrupt overhead should be nearly 0, but the overhead will mostly just have moved, but with real or potential gains to latency and throughput from parallelism (parallellism probably increases overheads a little but improves network throughput and latency at a cost to other concurrent uses of the CPUs that don't matter iff there ar CPU cycles to spare). (Overhead for fast interrupts is not accounted for accurately -- it will be charged to the interrupted context. The non-interrupt threads will be charged as "system".) Bruce From owner-freebsd-net@FreeBSD.ORG Sat Sep 12 13:36:26 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6776F106566C for ; Sat, 12 Sep 2009 13:36:26 +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 2D9DC8FC15 for ; Sat, 12 Sep 2009 13:36:25 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 022B1730DA; Sat, 12 Sep 2009 15:42:26 +0200 (CEST) Date: Sat, 12 Sep 2009 15:42:26 +0200 From: Luigi Rizzo To: rihad Message-ID: <20090912134226.GD46135@onelab2.iet.unipi.it> References: <4AAB4D56.30207@mail.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AAB4D56.30207@mail.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: [POLLING] strange interrupt/system load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 13:36:26 -0000 On Sat, Sep 12, 2009 at 12:27:18PM +0500, rihad wrote: > The box experiences ~230 mbit/s traffic flow through it. I've doubled > some sysctls after reading polling(4): > kern.polling.each_burst=10 # was: 5 > kern.polling.burst_max=350 # was: 150 > > FreeBSD 7.2-RELEASE-p3 amd64 > HZ=1000 > > Now for the fun part. > > With kern.polling.idle_poll = 1 top shows: > CPU: 0.0% user, 0.0% nice, 26.9% system, 3.1% interrupt, 70.0% idle > ~8000 interrupts/s total according to systat -vmstat: > 1999 cpu0: time > 2000 cpu1: time > 1999 cpu2: time > 1999 cpu3: time > > With kern.polling.idle_poll = 0 top shows: > CPU: 0.0% user, 0.0% nice, 0.0% system, 13.9% interrupt, 86.0% idle > Still the same ~8000 clock interrupts/s. > > Under both scenarios polling is enabled on both em0 and em1 through > ifconfig. > > > 1) Why is the interrupt load relatively high with polling enabled? > 2) How come 13.9% interrupts are not also in the first scenario if their > total rate is the same (~8000)? Polling enabled means that at every tick (and in the idle loop if you also have idle_poll enabled) you are checking the status of the interface even if there is no traffic. The polling handler is probably accounted for as 'interrupt'. The load you see shoud not be too different to what you see without polling. Enabling idle_poll moves part of the work to the idle loop(s) which are accounted as 'system' time. What happens here is that part of the work is taken away from the polling handlers that run on each tick so you see a reduction on the interrupt time, whereas as Bruce said, one CPU is using 100% of its time (or 25% of the total work capacity) to run the idle_poll loop. cheers luigi From owner-freebsd-net@FreeBSD.ORG Sat Sep 12 15:02:56 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94FE9106566B for ; Sat, 12 Sep 2009 15:02:56 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from mx75.mail.ru (mx75.mail.ru [94.100.176.90]) by mx1.freebsd.org (Postfix) with ESMTP id 52D1C8FC12 for ; Sat, 12 Sep 2009 15:02:56 +0000 (UTC) Received: from [217.25.27.27] (port=37246 helo=[217.25.27.27]) by mx75.mail.ru with asmtp id 1MmU7q-00092v-00; Sat, 12 Sep 2009 19:02:54 +0400 Message-ID: <4AABB81D.9070907@mail.ru> Date: Sat, 12 Sep 2009 20:02:53 +0500 From: rihad User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: Bruce Evans References: <4AAB4D56.30207@mail.ru> <20090912202529.X1569@besplex.bde.org> In-Reply-To: <20090912202529.X1569@besplex.bde.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Cc: freebsd-net@freebsd.org Subject: Re: [POLLING] strange interrupt/system load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 15:02:56 -0000 Bruce Evans wrote: > How much better does it work without POLLING? I'm not sure. It just works, How to measure it? I haven't noticed it adding any unacceptable latency to users' experience, making TCP/IP work less than optimal (we're an ISP). Once thing I did notice with POLLING enabled was that kern.polling.lost_polls was growing at a rate of2-3 per second, but after I enabled idle_poll the rate decreased to 1 lost poll every 10-15 seconds (burst_max & each_burst have been doubled in both scenarios). > On Sat, 12 Sep 2009, rihad wrote: > > POLLING is especially useless for em since its hardware has better > interrupt moderation than most NICs. In non-old versions of FreeBSD > em should be configured so as to not use it, and then em will use > fast interrupts and threads, a method that has a chance of working > much better than both POLLING and normal interrupts (but I haven't > actually seen it working much better). However, em's configuration > of this is bad: you have to not configure POLLING, and this prevents > use of polling on NICs that might actually benefit from it. > I understand it's not enough to just strip off the -polling part from the rc.conf line, but I also absolutely must rebuild the kernel with DEVICE_POLLING removed to get "fast em interrupts" working? Why, in theory, would ifconfigging some other nic, say, bce0, with polling alongside em0 without, not let em0 work without POLLING and bce0 with it? Mind you, I'm not using the deprecated kern.polling.enable sysctl: kern.polling.enable: 0 kern.polling.handlers: 2 I might as well have configured one interface with polling and one without. Or not? From owner-freebsd-net@FreeBSD.ORG Sat Sep 12 18:58:13 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A72221065670 for ; Sat, 12 Sep 2009 18:58:13 +0000 (UTC) (envelope-from ralph@imada.sdu.dk) Received: from berlioz.imada.sdu.dk (berlioz.imada.sdu.dk [130.225.128.12]) by mx1.freebsd.org (Postfix) with ESMTP id 64F158FC15 for ; Sat, 12 Sep 2009 18:58:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by localhost.imada.sdu.dk (Postfix) with ESMTP id C746F62703 for ; Sat, 12 Sep 2009 20:31:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at imada.sdu.dk Received: from berlioz.imada.sdu.dk ([127.0.0.1]) by localhost (berlioz.imada.sdu.dk [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 3yJ1BOpYX36r for ; Sat, 12 Sep 2009 18:31:42 +0000 (UTC) Received: from laptop.fullrate.dk (2110ds1-od.4.fullrate.dk [90.185.65.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by berlioz.imada.sdu.dk (Postfix) with ESMTP id BDBC862701 for ; Sat, 12 Sep 2009 20:31:41 +0200 (CEST) Message-ID: <4AABE908.5020201@imada.sdu.dk> Date: Sat, 12 Sep 2009 20:31:36 +0200 From: Ralph Zitz User-Agent: Thunderbird 2.0.0.23 (X11/20090911) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: bwi driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 18:58:13 -0000 Hello I'm the unfortunate owner of the unsupported "Intel WiFi Link 5100 AGN" card. Looking through some old hardware I found the following: "Linksys WPC54G version 3.1" pccard. I realize that the bwi driver lists as only supporting version 3, but might there be a chance my card works with the driver as well? When the card is inserted the kernel outputs the following: bwi0: mem 0xbf8a2000-0xbf8a3fff irq 16 at device 0.0 on cardbus0 bwi0: [ITHREAD] bwi0: no BBP id for device id 0x4318 device_attach: bwi0 attach returned 6 Regards, Ralph. From owner-freebsd-net@FreeBSD.ORG Sat Sep 12 19:00:18 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1ACA21065672 for ; Sat, 12 Sep 2009 19:00:18 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0A68B8FC12 for ; Sat, 12 Sep 2009 19:00:18 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8CJ0Hw9030380 for ; Sat, 12 Sep 2009 19:00:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8CJ0HJu030374; Sat, 12 Sep 2009 19:00:17 GMT (envelope-from gnats) Date: Sat, 12 Sep 2009 19:00:17 GMT Message-Id: <200909121900.n8CJ0HJu030374@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/138689: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 19:00:18 -0000 The following reply was made to PR kern/138689; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/138689: commit references a PR Date: Sat, 12 Sep 2009 18:55:27 +0000 (UTC) Author: bms Date: Sat Sep 12 18:55:15 2009 New Revision: 197129 URL: http://svn.freebsd.org/changeset/base/197129 Log: Fix an API issue in leave processing for IPv4 multicast groups. * Do not assume that the group lookup performed by imo_match_group() is valid when ifp is NULL in this case. * Instead, return EADDRNOTAVAIL if the ifp cannot be resolved for the membership we are being asked to leave. Caveat user: * The way IPv4 multicast memberships are implemented in the inpcb layer at the moment, has the side-effect that struct ip_moptions will still hold the membership, under the old ifp, until ip_freemoptions() is called for the parent inpcb. * The underlying issue is: the inpcb layer does not get notification of ifp being detached going away in a thread-safe manner. This is non-trivial to fix. But hey, at least the kernel should't panic when you unplug a card. PR: 138689 Submitted by: Stef Walter MFC after: 5 days Modified: head/sys/netinet/in_mcast.c Modified: head/sys/netinet/in_mcast.c ============================================================================== --- head/sys/netinet/in_mcast.c Sat Sep 12 18:24:31 2009 (r197128) +++ head/sys/netinet/in_mcast.c Sat Sep 12 18:55:15 2009 (r197129) @@ -2189,6 +2189,9 @@ inp_leave_group(struct inpcb *inp, struc if (!IN_MULTICAST(ntohl(gsa->sin.sin_addr.s_addr))) return (EINVAL); + if (ifp == NULL) + return (EADDRNOTAVAIL); + /* * Find the membership in the membership array. */ _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Sep 12 19:01:42 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 223541065697; Sat, 12 Sep 2009 19:01:42 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EE1AD8FC14; Sat, 12 Sep 2009 19:01:41 +0000 (UTC) Received: from freefall.freebsd.org (bms@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8CJ1fv6039527; Sat, 12 Sep 2009 19:01:41 GMT (envelope-from bms@freefall.freebsd.org) Received: (from bms@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8CJ1fEG039523; Sat, 12 Sep 2009 19:01:41 GMT (envelope-from bms) Date: Sat, 12 Sep 2009 19:01:41 GMT Message-Id: <200909121901.n8CJ1fEG039523@freefall.freebsd.org> To: stef@memberwebs.com, bms@FreeBSD.org, freebsd-net@FreeBSD.org From: bms@FreeBSD.org Cc: Subject: Re: kern/138689: [netinet] patch] Multicast: IP_DROP_MEMBERSHIP should return EADDRNOTAVAIL for invalid address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 19:01:42 -0000 Synopsis: [netinet] patch] Multicast: IP_DROP_MEMBERSHIP should return EADDRNOTAVAIL for invalid address State-Changed-From-To: open->patched State-Changed-By: bms State-Changed-When: Sat 12 Sep 2009 19:00:58 UTC State-Changed-Why: Committed to HEAD as rev 197129.· Thanks for your work in tracking down and fixing this issue. This fix deals with the POLA violation in the userland API, but doesn't fix the underlying issue, which requires a bit more thought. The inpcb layer will not learn about interfaces going down, even though the netinet stack cleans up its references to link-layer structures. To be frank: this situation comes about largely because getting the BSD network stack right for hot-swappable interfaces, requires swinging a big hammer around in a number of APIs and structures. In short, it's the sort of thing which gets chewed over at developer summits. ;-) IPv4 multicast structures are keyed by ifp. Should ifp be invalidated due to an interface being detached at runtime, and a userland consumer later tries to delete a membership, the lookup will fail. The membership will however still exist. There isn't really an easy way to deal with this, without implementing a full walk of all socket(s) with memberships on the ifp, and invalidating the inpcb's reference to the group, when in_ifdetach() is actually called on interface detach. The membership is eventually cleaned up by the call to inp_freemoptions() during the PCB cleanup when the socket is closed. It is a non-trivial issue to resolve, because it would involve taking socket-layer locks from a lower level path, leading to a lock order violation. Coding around issues in the stack is not really the right approach-- the better approach is to fix problems at source. Unfortunately, the project(s) involved are all separate, and communication hasn't really been that great between them in the past. That, and it takes a while for fixes to percolate into kernels because of release schedules. The code in Quagga looks really ugly, but I suppose this is what ends up happening in situations like this, where the development of stack components is not that cohesive. http://www.freebsd.org/cgi/query-pr.cgi?pr=138689 From owner-freebsd-net@FreeBSD.ORG Sat Sep 12 19:07:52 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82FDD1065672; Sat, 12 Sep 2009 19:07:52 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5ABFA8FC0C; Sat, 12 Sep 2009 19:07:52 +0000 (UTC) Received: from freefall.freebsd.org (bms@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8CJ7qlU039679; Sat, 12 Sep 2009 19:07:52 GMT (envelope-from bms@freefall.freebsd.org) Received: (from bms@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8CJ7qtM039675; Sat, 12 Sep 2009 19:07:52 GMT (envelope-from bms) Date: Sat, 12 Sep 2009 19:07:52 GMT Message-Id: <200909121907.n8CJ7qtM039675@freefall.freebsd.org> To: stef@memberwebs.com, bms@FreeBSD.org, freebsd-net@FreeBSD.org From: bms@FreeBSD.org Cc: Subject: Re: kern/138691: [netinet] [patch] Multicast: Keep membership and filters in sync X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 19:07:52 -0000 Synopsis: [netinet] [patch] Multicast: Keep membership and filters in sync State-Changed-From-To: open->patched State-Changed-By: bms State-Changed-When: Sat 12 Sep 2009 19:07:33 UTC State-Changed-Why: Committed to HEAD as SVN rev 197130, thanks! This is an obvious logic error that crept in during SSM refactoring, and should get MFCed as soon as possible. http://www.freebsd.org/cgi/query-pr.cgi?pr=138691 From owner-freebsd-net@FreeBSD.ORG Sat Sep 12 19:10:04 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24376106566B for ; Sat, 12 Sep 2009 19:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 13E638FC08 for ; Sat, 12 Sep 2009 19:10:04 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8CJA3LH039796 for ; Sat, 12 Sep 2009 19:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8CJA3oB039795; Sat, 12 Sep 2009 19:10:03 GMT (envelope-from gnats) Date: Sat, 12 Sep 2009 19:10:03 GMT Message-Id: <200909121910.n8CJA3oB039795@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/138691: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 19:10:04 -0000 The following reply was made to PR kern/138691; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/138691: commit references a PR Date: Sat, 12 Sep 2009 19:07:15 +0000 (UTC) Author: bms Date: Sat Sep 12 19:07:03 2009 New Revision: 197130 URL: http://svn.freebsd.org/changeset/base/197130 Log: Fix an obvious logic error in the IPv4 multicast leave processing, where the filter mode vector was not updated correctly after the leave. PR: 138691 Submitted by: Stef Walter MFC after: 5 days Modified: head/sys/netinet/in_mcast.c Modified: head/sys/netinet/in_mcast.c ============================================================================== --- head/sys/netinet/in_mcast.c Sat Sep 12 18:55:15 2009 (r197129) +++ head/sys/netinet/in_mcast.c Sat Sep 12 19:07:03 2009 (r197130) @@ -2278,9 +2278,11 @@ out_imf_rollback: imf_reap(imf); if (is_final) { - /* Remove the gap in the membership array. */ - for (++idx; idx < imo->imo_num_memberships; ++idx) + /* Remove the gap in the membership and filter array. */ + for (++idx; idx < imo->imo_num_memberships; ++idx) { imo->imo_membership[idx-1] = imo->imo_membership[idx]; + imo->imo_mfilters[idx-1] = imo->imo_mfilters[idx]; + } imo->imo_num_memberships--; } _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Sep 12 19:10:18 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F17511065672 for ; Sat, 12 Sep 2009 19:10:18 +0000 (UTC) (envelope-from ralph@imada.sdu.dk) Received: from berlioz.imada.sdu.dk (berlioz.imada.sdu.dk [130.225.128.12]) by mx1.freebsd.org (Postfix) with ESMTP id AD76B8FC12 for ; Sat, 12 Sep 2009 19:10:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by localhost.imada.sdu.dk (Postfix) with ESMTP id 3965D62708 for ; Sat, 12 Sep 2009 21:10:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at imada.sdu.dk Received: from berlioz.imada.sdu.dk ([127.0.0.1]) by localhost (berlioz.imada.sdu.dk [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id AspjN8tsWYLA for ; Sat, 12 Sep 2009 19:10:14 +0000 (UTC) Received: from laptop.fullrate.dk (2110ds1-od.4.fullrate.dk [90.185.65.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by berlioz.imada.sdu.dk (Postfix) with ESMTP id 2DF8862701 for ; Sat, 12 Sep 2009 21:10:14 +0200 (CEST) Message-ID: <4AABF215.10203@imada.sdu.dk> Date: Sat, 12 Sep 2009 21:10:13 +0200 From: Ralph Zitz User-Agent: Thunderbird 2.0.0.23 (X11/20090911) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4AABE908.5020201@imada.sdu.dk> In-Reply-To: <4AABE908.5020201@imada.sdu.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: bwi driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 19:10:19 -0000 Oh and this is on: FreeBSD 9.0-CURRENT #4 r197120 amd64 Ralph Zitz wrote: > Hello > > I'm the unfortunate owner of the unsupported "Intel WiFi Link 5100 > AGN" card. Looking through some old hardware I found the following: > "Linksys WPC54G version 3.1" pccard. I realize that the bwi driver > lists as only supporting version 3, but might there be a chance my > card works with the driver as well? > > When the card is inserted the kernel outputs the following: > bwi0: mem > 0xbf8a2000-0xbf8a3fff irq 16 at device 0.0 on cardbus0 > bwi0: [ITHREAD] > bwi0: no BBP id for device id 0x4318 > device_attach: bwi0 attach returned 6 > > Regards, > Ralph. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Sep 12 19:48:03 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AAC91065672; Sat, 12 Sep 2009 19:48:03 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 217AE8FC12; Sat, 12 Sep 2009 19:48:03 +0000 (UTC) Received: from freefall.freebsd.org (bms@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8CJm2O8080379; Sat, 12 Sep 2009 19:48:02 GMT (envelope-from bms@freefall.freebsd.org) Received: (from bms@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8CJm2LL080375; Sat, 12 Sep 2009 19:48:02 GMT (envelope-from bms) Date: Sat, 12 Sep 2009 19:48:02 GMT Message-Id: <200909121948.n8CJm2LL080375@freefall.freebsd.org> To: stef@memberwebs.com, bms@FreeBSD.org, freebsd-net@FreeBSD.org From: bms@FreeBSD.org Cc: Subject: Re: kern/138690: [netinet] [patch] multicast: uninited memory used in filter at IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 19:48:03 -0000 Synopsis: [netinet] [patch] multicast: uninited memory used in filter at IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP State-Changed-From-To: open->patched State-Changed-By: bms State-Changed-When: Sat 12 Sep 2009 19:46:44 UTC State-Changed-Why: An appropriate fix has been committed to HEAD as SVN rev 197132. [There was a potential issue further up with the handling of unspecified source on an existing inclusive group.] http://www.freebsd.org/cgi/query-pr.cgi?pr=138690 From owner-freebsd-net@FreeBSD.ORG Sat Sep 12 19:50:04 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5013D1065670 for ; Sat, 12 Sep 2009 19:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3F8138FC0A for ; Sat, 12 Sep 2009 19:50:04 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8CJo4wW080456 for ; Sat, 12 Sep 2009 19:50:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8CJo4bA080455; Sat, 12 Sep 2009 19:50:04 GMT (envelope-from gnats) Date: Sat, 12 Sep 2009 19:50:04 GMT Message-Id: <200909121950.n8CJo4bA080455@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/138690: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 19:50:04 -0000 The following reply was made to PR kern/138690; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/138690: commit references a PR Date: Sat, 12 Sep 2009 19:46:12 +0000 (UTC) Author: bms Date: Sat Sep 12 19:45:55 2009 New Revision: 197132 URL: http://svn.freebsd.org/changeset/base/197132 Log: Tighten input checking in inp_join_group(): * Don't try to use the source address, when its family is unspecified. * If we get a join without a source, on an existing inclusive mode group, this is an error, as it would change the filter mode. Fix a problem with the handling of in_mfilter for new memberships: * Do not rely on imf being NULL; it is explicitly initialized to a non-NULL pointer when constructing a membership. * Explicitly initialize *imf to EX mode when the source address is unspecified. This fixes a problem with in_mfilter slot recycling in the join path. PR: 138690 Submitted by: Stef Walter MFC after: 5 days Modified: head/sys/netinet/in_mcast.c Modified: head/sys/netinet/in_mcast.c ============================================================================== --- head/sys/netinet/in_mcast.c Sat Sep 12 19:27:54 2009 (r197131) +++ head/sys/netinet/in_mcast.c Sat Sep 12 19:45:55 2009 (r197132) @@ -1957,11 +1957,6 @@ inp_join_group(struct inpcb *inp, struct if (ifp == NULL || (ifp->if_flags & IFF_MULTICAST) == 0) return (EADDRNOTAVAIL); - /* - * MCAST_JOIN_SOURCE on an exclusive membership is an error. - * On an existing inclusive membership, it just adds the - * source to the filter list. - */ imo = inp_findmoptions(inp); idx = imo_match_group(imo, ifp, &gsa->sa); if (idx == -1) { @@ -1969,15 +1964,33 @@ inp_join_group(struct inpcb *inp, struct } else { inm = imo->imo_membership[idx]; imf = &imo->imo_mfilters[idx]; - if (ssa->ss.ss_family != AF_UNSPEC && - imf->imf_st[1] != MCAST_INCLUDE) { - error = EINVAL; - goto out_inp_locked; - } - lims = imo_match_source(imo, idx, &ssa->sa); - if (lims != NULL) { - error = EADDRNOTAVAIL; - goto out_inp_locked; + if (ssa->ss.ss_family != AF_UNSPEC) { + /* + * MCAST_JOIN_SOURCE on an exclusive membership + * is an error. On an existing inclusive membership, + * it just adds the source to the filter list. + */ + if (imf->imf_st[1] != MCAST_INCLUDE) { + error = EINVAL; + goto out_inp_locked; + } + /* Throw out duplicates. */ + lims = imo_match_source(imo, idx, &ssa->sa); + if (lims != NULL) { + error = EADDRNOTAVAIL; + goto out_inp_locked; + } + } else { + /* + * MCAST_JOIN_GROUP on an existing inclusive + * membership is an error; if you want to change + * filter mode, you must use the userland API + * setsourcefilter(). + */ + if (imf->imf_st[1] == MCAST_INCLUDE) { + error = EINVAL; + goto out_inp_locked; + } } } @@ -2010,7 +2023,8 @@ inp_join_group(struct inpcb *inp, struct /* * Graft new source into filter list for this inpcb's * membership of the group. The in_multi may not have - * been allocated yet if this is a new membership. + * been allocated yet if this is a new membership, however, + * the in_mfilter slot will be allocated and must be initialized. */ if (ssa->ss.ss_family != AF_UNSPEC) { /* Membership starts in IN mode */ @@ -2027,6 +2041,12 @@ inp_join_group(struct inpcb *inp, struct error = ENOMEM; goto out_imo_free; } + } else { + /* No address specified; Membership starts in EX mode */ + if (is_new) { + CTR1(KTR_IGMPV3, "%s: new join w/o source", __func__); + imf_init(imf, MCAST_UNDEFINED, MCAST_EXCLUDE); + } } /* _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Sep 12 20:18:52 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C748106568B; Sat, 12 Sep 2009 20:18:52 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D87548FC0A; Sat, 12 Sep 2009 20:18:51 +0000 (UTC) Received: from freefall.freebsd.org (bms@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8CKIptO009733; Sat, 12 Sep 2009 20:18:51 GMT (envelope-from bms@freefall.freebsd.org) Received: (from bms@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8CKIpqu009729; Sat, 12 Sep 2009 20:18:51 GMT (envelope-from bms) Date: Sat, 12 Sep 2009 20:18:51 GMT Message-Id: <200909122018.n8CKIpqu009729@freefall.freebsd.org> To: jhanna@pangolin-systems.com, bms@FreeBSD.org, freebsd-net@FreeBSD.org From: bms@FreeBSD.org Cc: Subject: Re: kern/137164: [netinet] [patch] assert panic imo_match_source() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 20:18:52 -0000 Synopsis: [netinet] [patch] assert panic imo_match_source() State-Changed-From-To: open->patched State-Changed-By: bms State-Changed-When: Sat 12 Sep 2009 20:17:38 UTC State-Changed-Why: Actually should be resolved by SVN rev 197132. See SVN rev 197135 for further tightening of the logic in this case. http://www.freebsd.org/cgi/query-pr.cgi?pr=137164 From owner-freebsd-net@FreeBSD.ORG Sat Sep 12 20:20:03 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0C2D1065679 for ; Sat, 12 Sep 2009 20:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 76E278FC12 for ; Sat, 12 Sep 2009 20:20:03 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8CKK3Kb009807 for ; Sat, 12 Sep 2009 20:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8CKK3nO009806; Sat, 12 Sep 2009 20:20:03 GMT (envelope-from gnats) Date: Sat, 12 Sep 2009 20:20:03 GMT Message-Id: <200909122020.n8CKK3nO009806@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/137164: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 20:20:03 -0000 The following reply was made to PR kern/137164; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/137164: commit references a PR Date: Sat, 12 Sep 2009 20:18:37 +0000 (UTC) Author: bms Date: Sat Sep 12 20:18:23 2009 New Revision: 197135 URL: http://svn.freebsd.org/changeset/base/197135 Log: Don't allow joins w/o source on an existing group. This is almost always pilot error. We don't need to check for group filter UNDEFINED state at t1, because we only ever allocate filters with their groups, so we unconditionally reject such calls with EINVAL. Trying to change the active filter mode w/o going through IP_MSFILTER is also disallowed. Deals with the case described in PR 137164 upfront, cumulative with the fix in svn rev 197132 which only calls imo_match_source() if the source address family was not unspecified. PR: 137164 MFC after: 5 days Modified: head/sys/netinet/in_mcast.c Modified: head/sys/netinet/in_mcast.c ============================================================================== --- head/sys/netinet/in_mcast.c Sat Sep 12 20:03:45 2009 (r197134) +++ head/sys/netinet/in_mcast.c Sat Sep 12 20:18:23 2009 (r197135) @@ -1982,15 +1982,18 @@ inp_join_group(struct inpcb *inp, struct } } else { /* - * MCAST_JOIN_GROUP on an existing inclusive - * membership is an error; if you want to change - * filter mode, you must use the userland API - * setsourcefilter(). + * MCAST_JOIN_GROUP alone, on any existing membership, + * is rejected, to stop the same inpcb tying up + * multiple refs to the in_multi. + * On an existing inclusive membership, this is also + * an error; if you want to change filter mode, + * you must use the userland API setsourcefilter(). + * XXX We don't reject this for imf in UNDEFINED + * state at t1, because allocation of a filter + * is atomic with allocation of a membership. */ - if (imf->imf_st[1] == MCAST_INCLUDE) { - error = EINVAL; - goto out_inp_locked; - } + error = EINVAL; + goto out_inp_locked; } } @@ -2025,6 +2028,9 @@ inp_join_group(struct inpcb *inp, struct * membership of the group. The in_multi may not have * been allocated yet if this is a new membership, however, * the in_mfilter slot will be allocated and must be initialized. + * + * Note: Grafting of exclusive mode filters doesn't happen + * in this path. */ if (ssa->ss.ss_family != AF_UNSPEC) { /* Membership starts in IN mode */ _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"