From owner-freebsd-net@FreeBSD.ORG Sun Jan 10 01:21:49 2010 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 3D3B11065723; Sun, 10 Jan 2010 01:21:49 +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 144BA8FC15; Sun, 10 Jan 2010 01:21:49 +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 o0A1Lm4s074367; Sun, 10 Jan 2010 01:21:48 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0A1LmZn074363; Sun, 10 Jan 2010 01:21:48 GMT (envelope-from linimon) Date: Sun, 10 Jan 2010 01:21:48 GMT Message-Id: <201001100121.o0A1LmZn074363@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: bin/142547: wpa_supplicant(8) drops connection on key renegotiation 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, 10 Jan 2010 01:21:49 -0000 Old Synopsis: wpa_supplicant drops connection on key renegotiation New Synopsis: wpa_supplicant(8) drops connection on key renegotiation Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jan 10 01:20:46 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=142547 From owner-freebsd-net@FreeBSD.ORG Sun Jan 10 09:30:05 2010 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 4F119106566B for ; Sun, 10 Jan 2010 09:30: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 251CD8FC12 for ; Sun, 10 Jan 2010 09:30:05 +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 o0A9U47N024905 for ; Sun, 10 Jan 2010 09:30:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0A9U4oo024900; Sun, 10 Jan 2010 09:30:04 GMT (envelope-from gnats) Date: Sun, 10 Jan 2010 09:30:04 GMT Message-Id: <201001100930.o0A9U4oo024900@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Bernhard Schmidt Cc: Subject: Re: bin/142547: wpa_supplicant(8) drops connection on key renegotiation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bernhard Schmidt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2010 09:30:05 -0000 The following reply was made to PR bin/142547; it has been noted by GNATS. From: Bernhard Schmidt To: bug-followup@freebsd.org, sweetpea-freebsd@tentacle.net Cc: Subject: Re: bin/142547: wpa_supplicant(8) drops connection on key renegotiation Date: Sun, 10 Jan 2010 10:28:14 +0100 Hi, can you confirm that this does also occur with iwn(4) from CURRENT or with http://forums.freebsd.org/showpost.php?p=47627&postcount=16 for STABLE? There has been quite some work done to iwn(4) which might have fixed that. -- Bernhard From owner-freebsd-net@FreeBSD.ORG Sun Jan 10 18:27:22 2010 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 D91331065694; Sun, 10 Jan 2010 18:27:21 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from asuka.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 373EA8FC1C; Sun, 10 Jan 2010 18:27:21 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:21b:d3ff:fe38:5381]) (user=ume mech=CRAM-MD5 bits=0) by asuka.mahoroba.org (8.14.3/8.14.3) with ESMTP/inet6 id o0AIRDYi072857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jan 2010 03:27:14 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Mon, 11 Jan 2010 03:27:13 +0900 Message-ID: From: Hajimu UMEMOTO To: David Horn In-Reply-To: <25ff90d61001021736p7b695197q104f4a7769b51b71@mail.gmail.com> References: <25ff90d60912162320y286e37a0ufeb64397716d8c18@mail.gmail.com> <25ff90d60912180612y2b1f64fbw34b4d7f648762087@mail.gmail.com> <25ff90d61001021736p7b695197q104f4a7769b51b71@mail.gmail.com> User-Agent: xcite1.58> Wanderlust/2.15.7 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.7 Emacs/23.1 (i386-portbld-freebsd8.0) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.0-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="Multipart_Mon_Jan_11_03:27:13_2010-1" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (asuka.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Mon, 11 Jan 2010 03:27:14 +0900 (JST) X-Virus-Scanned: clamav-milter 0.95.3 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on asuka.mahoroba.org Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: Unified rc.firewall ipfw me/me6 issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2010 18:27:23 -0000 --Multipart_Mon_Jan_11_03:27:13_2010-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, >>>>> On Sat, 2 Jan 2010 20:36:45 -0500 >>>>> David Horn said: > dhorn2000> Yes, "me" matching either ipv4/ipv6 would certainly simplify t= he default > dhorn2000> rc.firewall flow. > > Here is my proposed patch.  With this patch, 'me' matches to both IPv4 > and IPv6, and 'me4' is added for matching to only IPv4. dhorn2000> The patch for me4/me6 works perfect in my testing to date. I g= uess dhorn2000> we would need to convince a larger audience to get consensus on dhorn2000> changing the behavior for "me" token from just ipv4 to both ipv4= /ipv6, dhorn2000> but I personally think it is the right direction. Thank you for testing. I've added current@ and net@ to Cc:. It makes the IPv4/IPv6 dual stack rule definitely simpler that 'me' matches to both IPv4 and IPv6. I think it is desired feature. However, I'm not sure we actually need 'me4'. So, I split my previous patch into two patches. The 1st patch makes 'me' matches to both IPv4 and IPv6. The 2nd patch adds 'me4'. If there is no objection, I'll commit the 1st patch. If someone want 'me4', I'll commit the 2nd patch. And, the 3rd patch is for rc.firewall. dhorn2000> ipfw(8) man page already shows: dhorn2000> me matches any IP address configured on an interface in the dhorn2000> system. dhorn2000> me6 matches any IPv6 address configured on an interface in dhorn2000> the system. The address list is evaluated = at the time dhorn2000> the packet is analysed. I wish to believe this description about 'me' is correct. But, I'm not sure whether it is a feature or not. It might be that someone forgot to change it at the time when an IPv6 support was added to IPFW. Sincerely, --Multipart_Mon_Jan_11_03:27:13_2010-1 Content-Type: text/x-patch; type=patch; charset=US-ASCII Content-Disposition: attachment; filename="ipfw-me-unify.diff" Content-Transfer-Encoding: 7bit Index: sys/netinet/ipfw/ip_fw2.c diff -u -p sys/netinet/ipfw/ip_fw2.c.orig sys/netinet/ipfw/ip_fw2.c --- sys/netinet/ipfw/ip_fw2.c.orig 2010-01-05 04:01:22.000000000 +0900 +++ sys/netinet/ipfw/ip_fw2.c 2010-01-08 12:30:31.039834764 +0900 @@ -1390,7 +1390,14 @@ do { \ INADDR_TO_IFP(src_ip, tif); match = (tif != NULL); + break; } + /* FALLTHROUGH */ +#ifdef INET6 + case O_IP6_SRC_ME: + match = is_ipv6 && + search_ip6_addr_net(&args->f_id.src_ip6); +#endif break; case O_IP_DST_SET: @@ -1423,7 +1430,14 @@ do { \ INADDR_TO_IFP(dst_ip, tif); match = (tif != NULL); + break; } + /* FALLTHROUGH */ +#ifdef INET6 + case O_IP6_DST_ME: + match = is_ipv6 && + search_ip6_addr_net(&args->f_id.dst_ip6); +#endif break; case O_IP_SRCPORT: @@ -1691,14 +1705,6 @@ do { \ } break; - case O_IP6_SRC_ME: - match= is_ipv6 && search_ip6_addr_net(&args->f_id.src_ip6); - break; - - case O_IP6_DST_ME: - match= is_ipv6 && search_ip6_addr_net(&args->f_id.dst_ip6); - break; - case O_FLOW6ID: match = is_ipv6 && flow6id_match(args->f_id.flow_id6, --Multipart_Mon_Jan_11_03:27:13_2010-1 Content-Type: text/x-patch; type=patch; charset=US-ASCII Content-Disposition: attachment; filename="ipfw-me4.diff" Content-Transfer-Encoding: 7bit Index: sbin/ipfw/ipfw.8 diff -u sbin/ipfw/ipfw.8.orig sbin/ipfw/ipfw.8 --- sbin/ipfw/ipfw.8.orig 2009-12-15 18:46:27.000000000 +0900 +++ sbin/ipfw/ipfw.8 2010-01-08 12:33:36.117724529 +0900 @@ -1003,7 +1003,7 @@ its use is discouraged. .It Ar addr : Oo Cm not Oc Bro .Bl -tag -width indent -.Cm any | me | me6 | +.Cm any | me | me4 | me6 | .Cm table Ns Pq Ar number Ns Op , Ns Ar value .Ar | addr-list | addr-set .Brc @@ -1011,6 +1011,8 @@ matches any IP address. .It Cm me matches any IP address configured on an interface in the system. +.It Cm me4 +matches any IPv4 address configured on an interface in the system. .It Cm me6 matches any IPv6 address configured on an interface in the system. The address list is evaluated at the time the packet is Index: sbin/ipfw/ipfw2.c diff -u -p sbin/ipfw/ipfw2.c.orig sbin/ipfw/ipfw2.c --- sbin/ipfw/ipfw2.c.orig 2009-12-15 18:46:27.000000000 +0900 +++ sbin/ipfw/ipfw2.c 2010-01-08 12:33:36.037713520 +0900 @@ -768,6 +768,10 @@ print_ip(ipfw_insn_ip *cmd, char const * printf("me"); return; } + if (cmd->o.opcode == O_IP4_SRC_ME || cmd->o.opcode == O_IP4_DST_ME) { + printf("me4"); + return; + } if (cmd->o.opcode == O_IP_SRC_LOOKUP || cmd->o.opcode == O_IP_DST_LOOKUP) { printf("table(%u", ((ipfw_insn *)cmd)->arg1); @@ -1187,6 +1191,7 @@ show_ipfw(struct ip_fw *rule, int pcwidt case O_IP_SRC_LOOKUP: case O_IP_SRC_MASK: case O_IP_SRC_ME: + case O_IP4_SRC_ME: case O_IP_SRC_SET: show_prerequisites(&flags, HAVE_PROTO, 0); if (!(flags & HAVE_SRCIP)) @@ -1202,6 +1207,7 @@ show_ipfw(struct ip_fw *rule, int pcwidt case O_IP_DST_LOOKUP: case O_IP_DST_MASK: case O_IP_DST_ME: + case O_IP4_DST_ME: case O_IP_DST_SET: show_prerequisites(&flags, HAVE_PROTO|HAVE_SRCIP, 0); if (!(flags & HAVE_DSTIP)) @@ -1972,6 +1978,12 @@ fill_ip(ipfw_insn_ip *cmd, char *av) return; } + if (strcmp(av, "me4") == 0) { + cmd->o.opcode = O_IP4_DST_ME; + cmd->o.len |= F_INSN_SIZE(ipfw_insn); + return; + } + if (strncmp(av, "table(", 6) == 0) { char *p = strchr(av + 6, ','); @@ -2478,6 +2490,8 @@ add_srcip(ipfw_insn *cmd, char *av) cmd->opcode = O_IP_SRC_SET; else if (cmd->opcode == O_IP_DST_LOOKUP) /* table */ cmd->opcode = O_IP_SRC_LOOKUP; + else if (cmd->opcode == O_IP4_DST_ME) /* me4 */ + cmd->opcode = O_IP4_SRC_ME; else if (F_LEN(cmd) == F_INSN_SIZE(ipfw_insn)) /* me */ cmd->opcode = O_IP_SRC_ME; else if (F_LEN(cmd) == F_INSN_SIZE(ipfw_insn_u32)) /* one IP */ @@ -2495,6 +2509,8 @@ add_dstip(ipfw_insn *cmd, char *av) ; else if (cmd->opcode == O_IP_DST_LOOKUP) /* table */ ; + else if (cmd->opcode == O_IP4_DST_ME) /* me4 */ + ; else if (F_LEN(cmd) == F_INSN_SIZE(ipfw_insn)) /* me */ cmd->opcode = O_IP_DST_ME; else if (F_LEN(cmd) == F_INSN_SIZE(ipfw_insn_u32)) /* one IP */ @@ -2534,7 +2550,7 @@ add_src(ipfw_insn *cmd, char *av, u_char ret = add_srcip6(cmd, av); /* XXX: should check for IPv4, not !IPv6 */ if (ret == NULL && (proto == IPPROTO_IP || strcmp(av, "me") == 0 || - !inet_pton(AF_INET6, host, &a))) + strcmp(av, "me4") == 0 || !inet_pton(AF_INET6, host, &a))) ret = add_srcip(cmd, av); if (ret == NULL && strcmp(av, "any") != 0) ret = cmd; @@ -2560,7 +2576,7 @@ add_dst(ipfw_insn *cmd, char *av, u_char ret = add_dstip6(cmd, av); /* XXX: should check for IPv4, not !IPv6 */ if (ret == NULL && (proto == IPPROTO_IP || strcmp(av, "me") == 0 || - !inet_pton(AF_INET6, host, &a))) + strcmp(av, "me4") == 0 || !inet_pton(AF_INET6, host, &a))) ret = add_dstip(cmd, av); if (ret == NULL && strcmp(av, "any") != 0) ret = cmd; Index: sys/netinet/ip_fw.h diff -u sys/netinet/ip_fw.h.orig sys/netinet/ip_fw.h --- sys/netinet/ip_fw.h.orig 2009-12-23 04:01:47.000000000 +0900 +++ sys/netinet/ip_fw.h 2010-01-08 12:33:36.157742465 +0900 @@ -166,6 +166,8 @@ O_ALTQ, /* u32 = altq classif. qid */ O_DIVERTED, /* arg1=bitmap (1:loop, 2:out) */ O_TCPDATALEN, /* arg1 = tcp data len */ + O_IP4_SRC_ME, /* none */ + O_IP4_DST_ME, /* none */ O_IP6_SRC, /* address without mask */ O_IP6_SRC_ME, /* my addresses */ O_IP6_SRC_MASK, /* address with the mask */ Index: sys/netinet/ipfw/ip_fw2.c diff -u -p sys/netinet/ipfw/ip_fw2.c.orig sys/netinet/ipfw/ip_fw2.c --- sys/netinet/ipfw/ip_fw2.c.orig 2010-01-08 12:30:31.039834764 +0900 +++ sys/netinet/ipfw/ip_fw2.c 2010-01-08 12:38:30.778824466 +0900 @@ -1385,6 +1385,7 @@ do { \ break; case O_IP_SRC_ME: + case O_IP4_SRC_ME: if (is_ipv4) { struct ifnet *tif; @@ -1392,6 +1393,8 @@ do { \ match = (tif != NULL); break; } + if (cmd->opcode == O_IP4_SRC_ME) + break; /* FALLTHROUGH */ #ifdef INET6 case O_IP6_SRC_ME: @@ -1425,6 +1428,7 @@ do { \ break; case O_IP_DST_ME: + case O_IP4_DST_ME: if (is_ipv4) { struct ifnet *tif; @@ -1432,6 +1436,8 @@ do { \ match = (tif != NULL); break; } + if (cmd->opcode == O_IP4_DST_ME) + break; /* FALLTHROUGH */ #ifdef INET6 case O_IP6_DST_ME: Index: sys/netinet/ipfw/ip_fw_sockopt.c diff -u -p sys/netinet/ipfw/ip_fw_sockopt.c.orig sys/netinet/ipfw/ip_fw_sockopt.c --- sys/netinet/ipfw/ip_fw_sockopt.c.orig 2010-01-07 19:08:05.000000000 +0900 +++ sys/netinet/ipfw/ip_fw_sockopt.c 2010-01-08 12:33:36.237826387 +0900 @@ -529,6 +529,8 @@ check_ipfw_struct(struct ip_fw *rule, in case O_VERSRCREACH: case O_ANTISPOOF: case O_IPSEC: + case O_IP4_SRC_ME: + case O_IP4_DST_ME: #ifdef INET6 case O_IP6_SRC_ME: case O_IP6_DST_ME: --Multipart_Mon_Jan_11_03:27:13_2010-1 Content-Type: text/x-patch; type=patch; charset=US-ASCII Content-Disposition: attachment; filename="rc.firewall-me-unify.diff" Content-Transfer-Encoding: 7bit Index: etc/defaults/rc.conf diff -u etc/defaults/rc.conf.orig etc/defaults/rc.conf --- etc/defaults/rc.conf.orig 2010-01-02 04:09:40.000000000 +0900 +++ etc/defaults/rc.conf 2010-01-08 18:08:10.227416014 +0900 @@ -143,9 +143,7 @@ firewall_allowservices="" # List of IPs which have access to # $firewall_myservices for "workstation" # firewall. -firewall_trusted="" # List of IPv4s which have full access to this - # host for "workstation" firewall. -firewall_trusted_ipv6="" # List of IPv6s which have full access to this +firewall_trusted="" # List of IPs which have full access to this # host for "workstation" firewall. firewall_logdeny="NO" # Set to YES to log default denied incoming # packets for "workstation" firewall. Index: etc/rc.firewall diff -u etc/rc.firewall.orig etc/rc.firewall --- etc/rc.firewall.orig 2010-01-08 18:07:55.805178124 +0900 +++ etc/rc.firewall 2010-01-08 18:08:42.558168213 +0900 @@ -212,8 +212,8 @@ ${fwcmd} add pass all from me to ${net} ${fwcmd} add pass all from ${net} to me if [ -n "$net6" ]; then - ${fwcmd} add pass all from me6 to ${net6} - ${fwcmd} add pass all from ${net6} to me6 + ${fwcmd} add pass all from me to ${net6} + ${fwcmd} add pass all from ${net6} to me fi if [ -n "$net6" ]; then @@ -221,7 +221,7 @@ ${fwcmd} add pass all from fe80::/10 to ff02::/16 ${fwcmd} add pass all from ${net6} to ff02::/16 # Allow DHCPv6 - ${fwcmd} add pass udp from fe80::/10 to me6 546 + ${fwcmd} add pass udp from fe80::/10 to me 546 fi # Allow TCP through if setup succeeded @@ -232,30 +232,18 @@ # Allow setup of incoming email ${fwcmd} add pass tcp from any to me 25 setup - if [ -n "$net6" ]; then - ${fwcmd} add pass tcp from any to me6 25 setup - fi # Allow setup of outgoing TCP connections only ${fwcmd} add pass tcp from me to any setup - if [ -n "$net6" ]; then - ${fwcmd} add pass tcp from me6 to any setup - fi # Disallow setup of all other TCP connections ${fwcmd} add deny tcp from any to any setup # Allow DNS queries out in the world ${fwcmd} add pass udp from me to any 53 keep-state - if [ -n "$net6" ]; then - ${fwcmd} add pass udp from me6 to any 53 keep-state - fi # Allow NTP queries out in the world ${fwcmd} add pass udp from me to any 123 keep-state - if [ -n "$net6" ]; then - ${fwcmd} add pass udp from me6 to any 123 keep-state - fi # Everything else is denied by default, unless the # IPFIREWALL_DEFAULT_TO_ACCEPT option is set in your kernel @@ -402,25 +390,14 @@ # Allow setup of incoming email ${fwcmd} add pass tcp from any to me 25 setup - if [ -n "$inet6" ]; then - ${fwcmd} add pass tcp from any to me6 25 setup - fi # Allow access to our DNS ${fwcmd} add pass tcp from any to me 53 setup ${fwcmd} add pass udp from any to me 53 ${fwcmd} add pass udp from me 53 to any - if [ -n "$inet6" ]; then - ${fwcmd} add pass tcp from any to me6 53 setup - ${fwcmd} add pass udp from any to me6 53 - ${fwcmd} add pass udp from me6 53 to any - fi # Allow access to our WWW ${fwcmd} add pass tcp from any to me 80 setup - if [ -n "$inet6" ]; then - ${fwcmd} add pass tcp from any to me6 80 setup - fi # Reject&Log all setup of incoming connections from the outside ${fwcmd} add deny log ip4 from any to any in via ${oif} setup proto tcp @@ -434,15 +411,9 @@ # Allow DNS queries out in the world ${fwcmd} add pass udp from me to any 53 keep-state - if [ -n "$inet6" ]; then - ${fwcmd} add pass udp from me6 to any 53 keep-state - fi # Allow NTP queries out in the world ${fwcmd} add pass udp from me to any 123 keep-state - if [ -n "$inet6" ]; then - ${fwcmd} add pass udp from me6 to any 123 keep-state - fi # Everything else is denied by default, unless the # IPFIREWALL_DEFAULT_TO_ACCEPT option is set in your kernel @@ -477,18 +448,13 @@ # For services permitted below. ${fwcmd} add pass tcp from me to any established - if [ $ipv6_available -eq 0 ]; then - ${fwcmd} add pass tcp from me6 to any established - fi # Allow any connection out, adding state for each. ${fwcmd} add pass tcp from me to any setup keep-state ${fwcmd} add pass udp from me to any keep-state ${fwcmd} add pass icmp from me to any keep-state if [ $ipv6_available -eq 0 ]; then - ${fwcmd} add pass tcp from me6 to any setup keep-state - ${fwcmd} add pass udp from me6 to any keep-state - ${fwcmd} add pass ipv6-icmp from me6 to any keep-state + ${fwcmd} add pass ipv6-icmp from me to any keep-state fi # Allow DHCP. @@ -496,7 +462,7 @@ ${fwcmd} add pass udp from any 67 to me 68 in ${fwcmd} add pass udp from any 67 to 255.255.255.255 68 in if [ $ipv6_available -eq 0 ]; then - ${fwcmd} add pass udp from fe80::/10 to me6 546 in + ${fwcmd} add pass udp from fe80::/10 to me 546 in fi # Some servers will ping the IP while trying to decide if it's # still in use. @@ -525,21 +491,15 @@ for i in ${firewall_allowservices} ; do for j in ${firewall_myservices} ; do ${fwcmd} add pass tcp from $i to me $j - if [ $ipv6_available -eq 0 ]; then - ${fwcmd} add pass tcp from $i to me6 $j - fi done done # Allow all connections from trusted IPs. # Playing with the content of firewall_trusted could seriously # degrade the level of protection provided by the firewall. - for i in ${firewall_trusted} ; do + for i in ${firewall_trusted} ${firewall_trusted_ipv6}; do ${fwcmd} add pass ip from $i to me done - for i in ${firewall_trusted_ipv6} ; do - ${fwcmd} add pass all from $i to me6 - done ${fwcmd} add 65000 count ip from any to any --Multipart_Mon_Jan_11_03:27:13_2010-1 Content-Type: text/plain; charset=US-ASCII -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ --Multipart_Mon_Jan_11_03:27:13_2010-1-- From owner-freebsd-net@FreeBSD.ORG Sun Jan 10 18:44:28 2010 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 E31AB106566B; Sun, 10 Jan 2010 18:44:28 +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 A1A518FC0C; Sun, 10 Jan 2010 18:44:28 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 42D9B73106; Sun, 10 Jan 2010 19:52:32 +0100 (CET) Date: Sun, 10 Jan 2010 19:52:32 +0100 From: Luigi Rizzo To: Hajimu UMEMOTO Message-ID: <20100110185232.GA27907@onelab2.iet.unipi.it> References: <25ff90d60912162320y286e37a0ufeb64397716d8c18@mail.gmail.com> <25ff90d60912180612y2b1f64fbw34b4d7f648762087@mail.gmail.com> <25ff90d61001021736p7b695197q104f4a7769b51b71@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, David Horn , freebsd-ipfw@freebsd.org Subject: Re: Unified rc.firewall ipfw me/me6 issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2010 18:44:29 -0000 On Mon, Jan 11, 2010 at 03:27:13AM +0900, Hajimu UMEMOTO wrote: > Hi, > > >>>>> On Sat, 2 Jan 2010 20:36:45 -0500 > >>>>> David Horn said: > > > dhorn2000> Yes, "me" matching either ipv4/ipv6 would certainly simplify the default > > dhorn2000> rc.firewall flow. > > > > Here is my proposed patch. ??With this patch, 'me' matches to both IPv4 > > and IPv6, and 'me4' is added for matching to only IPv4. > > dhorn2000> The patch for me4/me6 works perfect in my testing to date. I guess > dhorn2000> we would need to convince a larger audience to get consensus on > dhorn2000> changing the behavior for "me" token from just ipv4 to both ipv4/ipv6, > dhorn2000> but I personally think it is the right direction. > > Thank you for testing. > I've added current@ and net@ to Cc:. > It makes the IPv4/IPv6 dual stack rule definitely simpler that 'me' > matches to both IPv4 and IPv6. I think it is desired feature. > However, I'm not sure we actually need 'me4'. So, I split my previous > patch into two patches. The 1st patch makes 'me' matches to both IPv4 > and IPv6. The 2nd patch adds 'me4'. > If there is no objection, I'll commit the 1st patch. If someone want > 'me4', I'll commit the 2nd patch. We only need one 'me' option that matches v4 and v6, because the other two can be implemented as 'ip4 me' and 'ip6 me' at no extra cost (the code for 'me' only scans the list corresponding to the actual address family of the packet). I would actually vote for removing the 'me6' microinstruction from the kernel, and implement it in /sbin/ipfw by generating 'ip6 me'. Feel free to commit the change yourself. cheers luigi From owner-freebsd-net@FreeBSD.ORG Sun Jan 10 19:40:42 2010 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 CA013106568D; Sun, 10 Jan 2010 19:40:42 +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 ABB6F8FC1C; Sun, 10 Jan 2010 19:40:42 +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 o0AJefGA028050; Sun, 10 Jan 2010 11:40:42 -0800 (PST) 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: Sun, 10 Jan 2010 11:40:34 -0800 Message-ID: In-Reply-To: <20100110185232.GA27907@onelab2.iet.unipi.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Unified rc.firewall ipfw me/me6 issue Thread-Index: AcqSJSaXOe/YiAX5TAqjTGXen62l7AAB4P+Q References: <25ff90d60912162320y286e37a0ufeb64397716d8c18@mail.gmail.com><25ff90d60912180612y2b1f64fbw34b4d7f648762087@mail.gmail.com><25ff90d61001021736p7b695197q104f4a7769b51b71@mail.gmail.com> <20100110185232.GA27907@onelab2.iet.unipi.it> From: "Li, Qing" To: "Luigi Rizzo" , "Hajimu UMEMOTO" Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, David Horn , freebsd-ipfw@freebsd.org Subject: RE: Unified rc.firewall ipfw me/me6 issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2010 19:40:42 -0000 >=20 > We only need one 'me' option that matches v4 and v6, because the > other two can be implemented as 'ip4 me' and 'ip6 me' at no extra > cost (the code for 'me' only scans the list corresponding to the > actual address family of the packet). I would actually vote for > removing the 'me6' microinstruction from the kernel, and implement > it in /sbin/ipfw by generating 'ip6 me'. >=20 I agree with Luigi. -- Qing From owner-freebsd-net@FreeBSD.ORG Sun Jan 10 20:50:32 2010 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 63B911065695 for ; Sun, 10 Jan 2010 20:50:32 +0000 (UTC) (envelope-from antoine.brodin.freebsd@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id F204E8FC0C for ; Sun, 10 Jan 2010 20:50:31 +0000 (UTC) Received: by fxm10 with SMTP id 10so7255297fxm.14 for ; Sun, 10 Jan 2010 12:50:20 -0800 (PST) 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=pTDPfN1G9GnDz/0WT3aThqLa0q+HuvD0a6IIS5mo2Ms=; b=LL+SqCXulLuwaLTD0YEqfsi4JUWN+rLINvKQVklDj9i5cC7PoGOzEMlo83Pd3d00aP JgW9LQPp86vn9uvUXAUdfQDIwUOel2IGPwgTU4ejwM02wVxihW9bqV0tHxjx58BxXoAp wkNzR0xrVHme+dd5o31nAKmWY45mqBxHsxuV0= 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=ntB0M0l1W68etrvu3e9AMZISTAiIvCUy8PSCowEYsL48Em5uI9ni7dEgpBnWcfX6/B DfaPwCCdzanmoiXX2nJRxEdV8sx3uYKRw1A2liAd1RsAQjlWfnEZLHLkOIV36HGPF4kZ WmPgXsMuaNdC7Os1TQQXpcIhpOI/WOA3CT+Aw= MIME-Version: 1.0 Sender: antoine.brodin.freebsd@gmail.com Received: by 10.239.183.209 with SMTP id v17mr1374445hbg.209.1263154845216; Sun, 10 Jan 2010 12:20:45 -0800 (PST) Date: Sun, 10 Jan 2010 21:20:45 +0100 X-Google-Sender-Auth: 3cca8932dea3c82f Message-ID: From: Antoine Brodin To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: MK_NETGRAPH and MK_ATM/MK_BLUETOOTH 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, 10 Jan 2010 20:50:32 -0000 Hi there, I am looking at PR 137487, world broken WITHOUT_NETGRAPH. Is it reasonable to have MK_NETGRAPH=no enforce MK_ATM=no and MK_BLUETOOTH=no? The bluetooth stack is implemented using the netgraph framework. Some bluetooth userland tools include netgraph headers or use netgraph sockets. There are 2 ATM stacks, netnatm and netgraph/atm. netgraph/atm obviously uses netgraph. For netnatm, this is not clear if there is a dependency: atmconfig(8) includes netgraph headers and some files in sys/contrib/ngatm/netnatm also include netgraph headers. Thanks in advance, Cheers, Antoine From owner-freebsd-net@FreeBSD.ORG Mon Jan 11 00:22:10 2010 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 0324E106566C for ; Mon, 11 Jan 2010 00:22:10 +0000 (UTC) (envelope-from skip@menantico.com) Received: from vms173013pub.verizon.net (vms173013pub.verizon.net [206.46.173.13]) by mx1.freebsd.org (Postfix) with ESMTP id D91A68FC19 for ; Mon, 11 Jan 2010 00:22:09 +0000 (UTC) Received: from mx.menantico.com ([unknown] [71.188.45.31]) by vms173013.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0KW2002G03OG6DE1@vms173013.mailsrvcs.net>; Sun, 10 Jan 2010 18:21:57 -0600 (CST) Date: Sun, 10 Jan 2010 19:29:23 -0500 From: Skip Ford To: Antoine Brodin Message-id: <20100111002923.GA1065@menantico.com> References: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: MK_NETGRAPH and MK_ATM/MK_BLUETOOTH 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, 11 Jan 2010 00:22:10 -0000 Antoine Brodin wrote: > I am looking at PR 137487, world broken WITHOUT_NETGRAPH. > Is it reasonable to have MK_NETGRAPH=no enforce MK_ATM=no and MK_BLUETOOTH=no? > The bluetooth stack is implemented using the netgraph framework. Some > bluetooth userland tools include netgraph headers or use netgraph > sockets. > There are 2 ATM stacks, netnatm and netgraph/atm. > netgraph/atm obviously uses netgraph. > For netnatm, this is not clear if there is a dependency: atmconfig(8) > includes netgraph headers and some files in sys/contrib/ngatm/netnatm > also include netgraph headers. For ATM, yes, it is reasonable to force MK_ATM to no if WITHOUT_NETGRAPH if defined, as natm as implemented requires netgraph. In theory, the native ATM stack should work w/out netgraph but not vice versa. Unfortunately, all ATM-related stacks and programs, including the old HARP stack that's now gone, were always hidden behind the same MK_ATM variable and nobody ever felt the need to split them, presumably because they always want ngatm and natm together. So, there really s/b a MK_NGATM which requires MK_ATM and a MK_ATM that doesn't need netgraph. If someone actually wants natm without ngatm someday, it can be fixed. I vote do it. -- Skip From owner-freebsd-net@FreeBSD.ORG Mon Jan 11 05:16:24 2010 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 22FD41065695 for ; Mon, 11 Jan 2010 05:16:24 +0000 (UTC) (envelope-from swun2010@gmail.com) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id F2B098FC1E for ; Mon, 11 Jan 2010 05:16:23 +0000 (UTC) Received: by pwi15 with SMTP id 15so1294023pwi.3 for ; Sun, 10 Jan 2010 21:16:18 -0800 (PST) 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:content-type; bh=4VwyZA3ijxaF78pSwR8twr9BuNbb0FbPxgnFJJup7uc=; b=EW6ec7ajm7S4epyNa6rUfT7MimOz8ZRbfn8Cs4/eYqBPgtIOhJo0yux7ryWnzH18si UNXNLwrFBB2V5Oyzi4yFosB6CM3A7DdCBSBmwxOgcP1AqA8KAL63p8MbmBUW3j3T65q9 f5SFFAPQBHb1jZ1PfKEkfI+rKppkqI+tutBAU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=CjdbvuSXeBUf31HxbKKuFeyVSk2d9HELimzEGz/2CSblAkgTnlYK+vKJfg8unckfYZ hO+OJjdsabOWqys+BVDqgYEgyVqx2ebQ56rzf9Q9gvzHkwkVcUVmPB4GI7jLpFQn1TtV gXyeYX2k09dxTARMMTFTPGKztC61OHksjjQY0= MIME-Version: 1.0 Received: by 10.141.187.39 with SMTP id o39mr1096120rvp.13.1263185389637; Sun, 10 Jan 2010 20:49:49 -0800 (PST) Date: Mon, 11 Jan 2010 15:49:49 +1100 Message-ID: <736c47cb1001102049v71757b78oe954fd39f9d03118@mail.gmail.com> From: Sam Wun To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: freebsd for Sun Fire X4250 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, 11 Jan 2010 05:16:24 -0000 Hi, This server is built with Xeon cpu processor, Intel based. Can FreeBSD 8+ fully compatible with this server like those ordinary Intel i386 machine? Thanks SW From owner-freebsd-net@FreeBSD.ORG Mon Jan 11 09:30:05 2010 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 A25AD1065670 for ; Mon, 11 Jan 2010 09:30: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 911E18FC15 for ; Mon, 11 Jan 2010 09:30:05 +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 o0B9U59o043699 for ; Mon, 11 Jan 2010 09:30:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0B9U58E043690; Mon, 11 Jan 2010 09:30:05 GMT (envelope-from gnats) Date: Mon, 11 Jan 2010 09:30:05 GMT Message-Id: <201001110930.o0B9U58E043690@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Dennis Yusupoff Cc: Subject: Re: kern/141843: [em] [vlan] Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dennis Yusupoff List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 09:30:05 -0000 The following reply was made to PR kern/141843; it has been noted by GNATS. From: Dennis Yusupoff To: pyunyh@gmail.com, bug-followup@FreeBSD.org Cc: Subject: Re: kern/141843: [em] [vlan] Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets Date: Mon, 11 Jan 2010 12:20:46 +0300 30.12.2009 23:20, Pyun YongHyeon пишет: > > Sorry, that wasn't expected one. From your explanation above I > think I found a possible cause of checksum offload issue of em(4). > The issue was not I initially thought though. It seems the checksum > offload context configured in em(4) was incorrectly reused even if > a frame requires a new context as IP/TCP header length, checksum > offload offset was changed. Setting up new context put more burden > to hardware such that em(4) used to avoid new context setup as > possible as it can. However it seems em(4) failed to compare all > required field in the checksum offload context. Would you try the > following patch again? > > http://people.freebsd.org/~yongari/em.csum_tso.20091230.patch Gotcha! It works! --- With best regards, Dennis Yusupoff, network engineer of Smart-Telecom ISP Russia, Saint-Petersburg From owner-freebsd-net@FreeBSD.ORG Mon Jan 11 09:45:11 2010 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 A0D6A1065670; Mon, 11 Jan 2010 09:45:11 +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 78C438FC0C; Mon, 11 Jan 2010 09:45:11 +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 o0B9jBk0061573; Mon, 11 Jan 2010 09:45:11 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0B9jBUu061569; Mon, 11 Jan 2010 09:45:11 GMT (envelope-from linimon) Date: Mon, 11 Jan 2010 09:45:11 GMT Message-Id: <201001110945.o0B9jBUu061569@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/142518: [em] [lagg] Problem on 8.0-STABLE with em and lagg 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, 11 Jan 2010 09:45:11 -0000 Old Synopsis: Problem on 8.0-STABLE with em and lagg New Synopsis: [em] [lagg] Problem on 8.0-STABLE with em and lagg Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jan 11 09:44:54 UTC 2010 Responsible-Changed-Why: This does not sound i386-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=142518 From owner-freebsd-net@FreeBSD.ORG Mon Jan 11 11:07:05 2010 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 88CDB1065693 for ; Mon, 11 Jan 2010 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 774F48FC19 for ; Mon, 11 Jan 2010 11:07:05 +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 o0BB75JE034735 for ; Mon, 11 Jan 2010 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0BB74kJ034733 for freebsd-net@FreeBSD.org; Mon, 11 Jan 2010 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 11 Jan 2010 11:07:04 GMT Message-Id: <201001111107.o0BB74kJ034733@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, 11 Jan 2010 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 bin/142547 net wpa_supplicant(8) drops connection on key renegotiatio o kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142392 net [panic] rtadvd(8) triggers kernel panic when started f o kern/142391 net [panic] bsnmpd(8) triggers kernel panic when a second o kern/142019 net [em] em needs "ifconfig em0 down up" when link was gon o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 o kern/141843 net [em] [vlan] Intel txcsum and assigned vlan invoke wron o kern/141777 net [rum] [patch] Support usbdevs / rum(4) for Buffalo WLI f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141720 net [sctp] [lor] [hang] sctp-create vs. sctp-it causes sys o kern/141698 net [sctp] [panic] Own lock on stcb at return from input o kern/141697 net [sctp] [panic] lock (sleep mutex) sctp-tcb not locked o kern/141696 net [rum] [panic] rum(4)+ vimage = kernel panic o kern/141695 net [sctp] [panic] kernel page fault with non-sleepable lo o kern/141646 net [em] em(4) + lagg(4) + vlan(4) generates ISL-tagged fr o kern/141314 net Network Performance has decreased by 30% [regression] o kern/141285 net [em] hangs down/up intel nic during creating vlan o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140970 net [bce] The two NetXtreme II BCM5709S NICs on our HP Bl4 o kern/140796 net [ath] [panic] privileged instruction fault o kern/140778 net [em] randomly panic in vlan/em o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140728 net [em] [patch] Fast irq registration in em driver o kern/140684 net [bce] Broadcom NetXtreme II BCM5709 1000Base-T - fail o kern/140647 net [em] [patch] e1000 driver does not correctly handle mu o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc s kern/140597 net [request] implement Lost Retransmission Detection o kern/140567 net [ath] [patch] ath is not worked on my notebook PC o kern/140564 net [wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140326 net [em] em0: watchdog timeout when communicating to windo o kern/140245 net [ath] [panic] Kernel panic during network activity on o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/140051 net [bce] [arp] ARP not sent through Bridge Firewall with o kern/140036 net [iwn] [lor] lock order reversal with iwn0_com_lock and o kern/139761 net [bce] bce driver on IBM HS22 [No PHY found on Child MI o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139162 net [fwip] [panic] 8.0-RC1 panics if using IP over firewir o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139079 net [wpi] Failure to attach wpi(4) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138999 net [libc] lighttpd/php-cgi with freebsd sendfile(2) enabl o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o kern/138694 net [bge] FreeBSD 6.3 release does not recognize Broadcom o amd64/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop f kern/138666 net [multicast] [panic] not working multicast through igmp o kern/138660 net [igb] igb driver troubles in 8.0-BETA4 o kern/138652 net [tcp] TCP window scaling value calculated incorrectly? o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked 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/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR on 8.0-BE o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 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 p 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/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 bin/136661 net [patch] ndp(8) ignores -f option 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/136426 net [panic] spawning several dhclients in parallel panics 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/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/133786 net [netinet] [patch] ip_input might cause kernel panic 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 f kern/133213 net arp and sshd errors on 7.1-PRERELEASE 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/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 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/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 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/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/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 [if_em] 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 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 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/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/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s 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 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] [patch] if_sis short cable fix problems with Net 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 383 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jan 11 21:53:26 2010 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 9F6E81065672 for ; Mon, 11 Jan 2010 21:53:26 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by mx1.freebsd.org (Postfix) with ESMTP id 597788FC0C for ; Mon, 11 Jan 2010 21:53:26 +0000 (UTC) X-AuditID: 1209190f-b7cabae000000a48-56-4b4b9dd5da71 Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by dmz-mailsec-scanner-4.mit.edu (Symantec Brightmail Gateway) with SMTP id 25.BC.02632.5DD9B4B4; Mon, 11 Jan 2010 16:53:25 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id o0BLqfxT022079; Mon, 11 Jan 2010 16:52:41 -0500 (EST) Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id o0BLrcQC019290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Jan 2010 16:53:39 -0500 (EST) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id o0BLrNu8015731; Mon, 11 Jan 2010 16:53:23 -0500 (EST) Date: Mon, 11 Jan 2010 16:53:22 -0500 (EST) From: Benjamin Kaduk To: bug-followup@MIT.EDU In-Reply-To: <4ad871310911280904h10b6ab16gc0d73057973ebf08@mail.gmail.com> Message-ID: References: <200911240230.nAO2U6Ak004167@freefall.freebsd.org> <4ad871310911280904h10b6ab16gc0d73057973ebf08@mail.gmail.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Scanned-By: MIMEDefang 2.42 X-Brightmail-Tracker: AAAABAKSdvESV7SgEle1dRJXuMk= Cc: freebsd-net@freebsd.org Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock 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, 11 Jan 2010 21:53:26 -0000 To follow-up after a fairly long hiatus: I had been running Bernhard's driver from his svn repository for a while with no LORs. Over the weekend, I updated past FreeBSD r201882 to pick up Rui's big update from r201209 as well as the firmware error fix in r201882. I do not see the LOR anymore (and I had a rather repeatable test case), so I think that this PR should be closed. I didn't have a reliable way to reproduce the firmware error, though, so no data if that is fixed for me, too. -Ben Kaduk From owner-freebsd-net@FreeBSD.ORG Mon Jan 11 23:00:11 2010 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 336891065670 for ; Mon, 11 Jan 2010 23:00:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2326B8FC12 for ; Mon, 11 Jan 2010 23:00:11 +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 o0BN0AY1053156 for ; Mon, 11 Jan 2010 23:00:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0BN0At7053155; Mon, 11 Jan 2010 23:00:10 GMT (envelope-from gnats) Date: Mon, 11 Jan 2010 23:00:10 GMT Message-Id: <201001112300.o0BN0At7053155@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Benjamin Kaduk Cc: Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Benjamin Kaduk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 23:00:11 -0000 The following reply was made to PR kern/140036; it has been noted by GNATS. From: Benjamin Kaduk To: bug-followup@freebsd.org Cc: Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock Date: Mon, 11 Jan 2010 17:51:17 -0500 (EST) Helps if I complete the domain name ... ---------- Forwarded message ---------- Date: Mon, 11 Jan 2010 16:53:22 -0500 (EST) From: Benjamin Kaduk To: bug-followup@mit.edu Cc: freebsd-net@freebsd.org Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock To follow-up after a fairly long hiatus: I had been running Bernhard's driver from his svn repository for a while with no LORs. Over the weekend, I updated past FreeBSD r201882 to pick up Rui's big update from r201209 as well as the firmware error fix in r201882. I do not see the LOR anymore (and I had a rather repeatable test case), so I think that this PR should be closed. I didn't have a reliable way to reproduce the firmware error, though, so no data if that is fixed for me, too. -Ben Kaduk From owner-freebsd-net@FreeBSD.ORG Mon Jan 11 23:05:11 2010 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 0686F106568B for ; Mon, 11 Jan 2010 23:05:11 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.freebsd.org (Postfix) with ESMTP id 90AD18FC08 for ; Mon, 11 Jan 2010 23:05:10 +0000 (UTC) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw0.york.ac.uk (8.13.6/8.13.6) with ESMTP id o0BN55rh018581; Mon, 11 Jan 2010 23:05:05 GMT Received: from ury.york.ac.uk ([144.32.108.81]) by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1NUTJp-00075a-2E; Mon, 11 Jan 2010 23:05:05 +0000 Received: from ury.york.ac.uk (localhost.york.ac.uk [127.0.0.1]) by ury.york.ac.uk (8.14.3/8.14.3) with ESMTP id o0BN54FZ038434; Mon, 11 Jan 2010 23:05:04 GMT (envelope-from gavin@FreeBSD.org) Received: from localhost (gavin@localhost) by ury.york.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id o0BN54RQ038431; Mon, 11 Jan 2010 23:05:04 GMT (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: ury.york.ac.uk: gavin owned process doing -bs Date: Mon, 11 Jan 2010 23:05:04 +0000 (GMT) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: Sam Wun In-Reply-To: <736c47cb1001102049v71757b78oe954fd39f9d03118@mail.gmail.com> Message-ID: References: <736c47cb1001102049v71757b78oe954fd39f9d03118@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-net@FreeBSD.org Subject: Re: freebsd for Sun Fire X4250 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, 11 Jan 2010 23:05:11 -0000 On Mon, 11 Jan 2010, Sam Wun wrote: > This server is built with Xeon cpu processor, Intel based. > Can FreeBSD 8+ fully compatible with this server like those ordinary > Intel i386 machine? Although it's hard to say (the Sun website doesn't realy give enough spec details), I'd be surprised if it doesn't work. FreeBSD runs very nicely on every Intel- and amd64-based Sun machine I've tried it on. You'll almost certainly want to use the FreeBSD amd64 release rather than i386, and I'd probably recommend 8.0-RELEASE, although 7.2 should work fine. By the way, this is the wrong list for questions like this: if you have any others, you're probably best off directing them to freebsd-questions@FreeBSD.org Gavin From owner-freebsd-net@FreeBSD.ORG Mon Jan 11 23:06:13 2010 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 AFA391065692 for ; Mon, 11 Jan 2010 23:06:13 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 0DE1C8FC14 for ; Mon, 11 Jan 2010 23:06:12 +0000 (UTC) Received: by bwz5 with SMTP id 5so14182098bwz.3 for ; Mon, 11 Jan 2010 15:06:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=FsNrR4g8RHGVuGNPuWVv3zWK+BWa4cQOdgqVlt+MMyc=; b=M2RT6wjI1fJQnwk8TMalfTsgrrPrScTS7Hs4KySUgK+QntQpQ9iViAw7CflAc8HocP uHgEuRWUznjmy5HRQ7g4FXVpSZb8FI4hM/cPfW+YGd+ioH+grqj3spuSZESWHcLaEnyx at9FGbc9CjziVNU9DrBqpQ4GA00bBhw0Jad9k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=U+4xotVc4kQ1dZwjnzNNnm9E7u9PL8gm5dGrO49kXaCiubUiqfaI7CUrKWRMQsdXjg 4zS0OPLuPwSfjm9i7fiORbLmDrnfo0LFnEWlwsgy/0iyDqQ2isbxOIj9CyrSJZ4iJS92 uxQTlKcC7E+UAUsVBfodv6MTVaLxolGSwOHsA= MIME-Version: 1.0 Received: by 10.204.157.24 with SMTP id z24mr4520786bkw.208.1263249670237; Mon, 11 Jan 2010 14:41:10 -0800 (PST) From: Maxim Ignatenko Date: Tue, 12 Jan 2010 00:40:50 +0200 Message-ID: To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: ng_patch node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 23:06:13 -0000 Hi, I've written netgraph node able to modify arbitrary (8|16|32)-bit unsigned integer in passing packets. Node applies one of =,+,-,&,| and ^ operations to number at given offset. Modification applied to each packet received on "in" hook. If "out" hook is connected - resulting packets passed on it, otherwise - returned back on "in" (for more easy use with ng_ipfw). Packets received on "out" hook passed on "in" unmodified. Node supports two control messages: "getconfig" and "setconfig". Configuration represented in next structure: struct ng_patch_config { uint32_t value; /* argument passed to requested operation */ uint32_t offset; /* offset in bytes */ uint32_t length; /* 1,2 or 4 bytes */ uint32_t mode; /* operation code: 1 - "=", 2 - "+", 3 - "-", 4 - "&", 5 - "|", 6 - "^" */ }; Same names used in ASCII representation. I wanted to make ipfw able to modify TTL and ToS fields in IP packets, but after some generalization idea looked like described above. Next patch made against 8-STABLE r200201 Index: modules/netgraph/patch/Makefile =================================================================== --- modules/netgraph/patch/Makefile (revision 0) +++ modules/netgraph/patch/Makefile (revision 0) @@ -0,0 +1,6 @@ +# $FreeBSD$ + +KMOD= ng_patch +SRCS= ng_patch.c + +.include Index: netgraph/ng_patch.c =================================================================== --- netgraph/ng_patch.c (revision 0) +++ netgraph/ng_patch.c (revision 0) @@ -0,0 +1,393 @@ +/* + * ng_patch.c + */ + +/*- + * Copyright (C) 2010 by Maxim Ignatenko + * All rights reserved. * + * * + * Redistribution and use in source and binary forms, with or without * + * modification, are permitted provided that the following conditions * + * are met: * + * * Redistributions of source code must retain the above copyright * + * notice, this list of conditions and the following disclaimer. * + * * Redistributions in binary form must reproduce the above copyright * + * notice, this list of conditions and the following disclaimer in * + * the documentation and/or other materials provided with the * + * distribution. * + * * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS * + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT * + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR * + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT * + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, * + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY * + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT * + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE * + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * + * + * Author: Maxim Ignatenko + * + * $FreeBSD$ + */ + +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +static ng_constructor_t ng_patch_constructor; +static ng_rcvmsg_t ng_patch_rcvmsg; +static ng_shutdown_t ng_patch_shutdown; +static ng_newhook_t ng_patch_newhook; +static ng_rcvdata_t ng_patch_rcvdata; +static ng_disconnect_t ng_patch_disconnect; + +/* Parse type for struct ngpatchstat */ +static const struct ng_parse_struct_field ng_patch_config_type_fields[] + = NG_PATCH_CONFIG_TYPE_INFO; +static const struct ng_parse_type ng_patch_config_type = { + &ng_parse_struct_type, + &ng_patch_config_type_fields +}; + +/* List of commands and how to convert arguments to/from ASCII */ +static const struct ng_cmdlist ng_patch_cmdlist[] = { + { + NGM_PATCH_COOKIE, + NGM_PATCH_GETCONFIG, + "getconfig", + NULL, + &ng_patch_config_type, + }, + { + NGM_PATCH_COOKIE, + NGM_PATCH_SETCONFIG, + "setconfig", + &ng_patch_config_type, + NULL + }, + { 0 } +}; + +/* Netgraph node type descriptor */ +static struct ng_type typestruct = { + .version = NG_ABI_VERSION, + .name = NG_PATCH_NODE_TYPE, + .constructor = ng_patch_constructor, + .rcvmsg = ng_patch_rcvmsg, + .shutdown = ng_patch_shutdown, + .newhook = ng_patch_newhook, + .rcvdata = ng_patch_rcvdata, + .disconnect = ng_patch_disconnect, + .cmdlist = ng_patch_cmdlist, +}; +NETGRAPH_INIT(patch, &typestruct); + +/* Information we store for each node */ +struct ng_patch_priv { + hook_p in; + hook_p out; + node_p node; /* back pointer to node */ + uint8_t value1; + uint16_t value2; + uint32_t value4; + struct ng_patch_config config; +}; +typedef struct ng_patch_priv *priv_p; + +static int +ng_patch_constructor(node_p node) +{ + priv_p privdata; + + /* Initialize private descriptor */ + privdata = malloc(sizeof(*privdata), M_NETGRAPH, + M_NOWAIT | M_ZERO); + if (privdata == NULL) + return (ENOMEM); + + /* Link structs together; this counts as our one reference to *nodep */ + NG_NODE_SET_PRIVATE(node, privdata); + privdata->node = node; + privdata->in = NULL; + privdata->out = NULL; + return (0); +} + +static int +ng_patch_newhook(node_p node, hook_p hook, const char *name) +{ + const priv_p patchp = NG_NODE_PRIVATE(node); + + if (strncmp(name, NG_PATCH_HOOK_IN, + strlen(NG_PATCH_HOOK_IN)) == 0) { + patchp->in = hook; + } else if (strncmp(name, NG_PATCH_HOOK_OUT, + strlen(NG_PATCH_HOOK_OUT)) == 0) { + patchp->out = hook; + } else + return (EINVAL); + return(0); +} + +/* + * Get a netgraph control message. + */ +static int +ng_patch_rcvmsg(node_p node, item_p item, hook_p lasthook) +{ + const priv_p patchp = NG_NODE_PRIVATE(node); + struct ng_mesg *resp = NULL; + int error = 0; + struct ng_mesg *msg; + + NGI_GET_MSG(item, msg); + /* Deal with message according to cookie and command */ + switch (msg->header.typecookie) { + case NGM_PATCH_COOKIE: + switch (msg->header.cmd) { + case NGM_PATCH_GETCONFIG: + { + struct ng_patch_config *conf; + + NG_MKRESPONSE(resp, msg, sizeof(*conf), M_NOWAIT); + if (!resp) { + error = ENOMEM; + break; + } + conf = (struct ng_patch_config *) resp->data; + conf->value = patchp->config.value; + conf->offset = patchp->config.offset; + conf->length = patchp->config.length; + conf->mode = patchp->config.mode; + break; + } + case NGM_PATCH_SETCONFIG: + if (msg->header.arglen != sizeof(struct ng_patch_config)) { + error = EINVAL; + break; + } + switch (((struct ng_patch_config *)msg->data)->length) + { + case 1: + case 2: + case 4: + break; + default: + error = EINVAL; + } + if (((struct ng_patch_config *)msg->data)->offset < 0) + error = EINVAL; + if (error == 0) { + patchp->config = *((struct ng_patch_config *) msg->data); + patchp->value1 = patchp->config.value; + patchp->value2 = patchp->config.value; + patchp->value4 = patchp->config.value; + } + break; + default: + error = EINVAL; /* unknown command */ + break; + } + break; + default: + error = EINVAL; /* unknown cookie type */ + break; + } + + /* Take care of synchronous response, if any */ + NG_RESPOND_MSG(error, node, item, resp); + /* Free the message and return */ + NG_FREE_MSG(msg); + return(error); +} + +/* + * Receive data, and do something with it. + */ +static int +ng_patch_rcvdata(hook_p hook, item_p item ) +{ + const priv_p priv = NG_NODE_PRIVATE(NG_HOOK_NODE(hook)); + int error; + struct mbuf *m; + hook_p target; + uint8_t *dst; + + + NGI_GET_M(item, m); + if (hook == priv->in && + m->m_pkthdr.len >= priv->config.offset + priv->config.length) { + /* TODO: maybe better to use m_pulldown here */ + if ((m = m_pullup(m,priv->config.offset + priv->config.length)) == NULL) { + NG_FREE_ITEM(item); + return (ENOBUFS); + } + dst = mtod(m, uint8_t *); + dst = dst + priv->config.offset; + switch (priv->config.mode) + { + case NG_PATCH_MODE_SET: + switch (priv->config.length) + { + case 1: + *dst = priv->value1; + break; + case 2: + *((uint16_t *)dst) = priv->value2; + break; + case 4: + *((uint32_t *)dst) = priv->value4; + break; + } + break; + case NG_PATCH_MODE_ADD: + switch (priv->config.length) + { + case 1: + *dst += priv->value1; + break; + case 2: + *((uint16_t *)dst) += priv->value2; + break; + case 4: + *((uint32_t *)dst) += priv->value4; + break; + } + break; + case NG_PATCH_MODE_SUB: + switch (priv->config.length) + { + case 1: + *dst -= priv->value1; + break; + case 2: + *((uint16_t *)dst) -= priv->value2; + break; + case 4: + *((uint32_t *)dst) -= priv->value4; + break; + } + break; + case NG_PATCH_MODE_AND: + switch (priv->config.length) + { + case 1: + *dst &= priv->value1; + break; + case 2: + *((uint16_t *)dst) &= priv->value2; + break; + case 4: + *((uint32_t *)dst) &= priv->value4; + break; + } + break; + case NG_PATCH_MODE_OR: + switch (priv->config.length) + { + case 1: + *dst |= priv->value1; + break; + case 2: + *((uint16_t *)dst) |= priv->value2; + break; + case 4: + *((uint32_t *)dst) |= priv->value4; + break; + } + break; + case NG_PATCH_MODE_XOR: + switch (priv->config.length) + { + case 1: + *dst ^= priv->value1; + break; + case 2: + *((uint16_t *)dst) ^= priv->value2; + break; + case 4: + *((uint32_t *)dst) ^= priv->value4; + break; + } + break; + } + } + + target = NULL; + if (hook == priv->in) { + if (priv->out != NULL) + target = priv->out; + else + target = priv->in; /* return frames on 'in' hook if 'out' not connected*/ + } + if (hook == priv->out && priv->in != NULL) + target = priv->in; + + if (target == NULL) { + NG_FREE_ITEM(item); + NG_FREE_M(m); + return 0; + } + + NG_FWD_NEW_DATA(error, item, target, m); + + return (error); +} + +/* + * Do local shutdown processing.. + */ +static int +ng_patch_shutdown(node_p node) +{ + const priv_p privdata = NG_NODE_PRIVATE(node); + +#ifndef PERSISTANT_NODE + NG_NODE_SET_PRIVATE(node, NULL); + NG_NODE_UNREF(node); + free(privdata, M_NETGRAPH); +#else + if (node->nd_flags & NGF_REALLY_DIE) { + NG_NODE_SET_PRIVATE(node, NULL); + NG_NODE_UNREF(privdata->node); + free(privdata, M_NETGRAPH); + return (0); + } + NG_NODE_REVIVE(node); /* tell ng_rmnode() we will persist */ +#endif /* PERSISTANT_NODE */ + return (0); +} + +/* + * Hook disconnection + * + * For this type, removal of the last link destroys the node + */ +static int +ng_patch_disconnect(hook_p hook) +{ + priv_p priv=NG_NODE_PRIVATE(NG_HOOK_NODE(hook)); + + if (hook == priv->in) { + priv->in = NULL; + } + if (hook == priv->out) { + priv->out = NULL; + } + if ((NG_NODE_NUMHOOKS(NG_HOOK_NODE(hook)) == 0) + && (NG_NODE_IS_VALID(NG_HOOK_NODE(hook)))) /* already shutting down? */ + ng_rmnode_self(NG_HOOK_NODE(hook)); + return (0); +} + Index: netgraph/ng_patch.h =================================================================== --- netgraph/ng_patch.h (revision 0) +++ netgraph/ng_patch.h (revision 0) @@ -0,0 +1,78 @@ +/* + * ng_patch.h + */ + +/*- + * Copyright (C) 2010 by Maxim Ignatenko + * All rights reserved. * + * * + * Redistribution and use in source and binary forms, with or without * + * modification, are permitted provided that the following conditions * + * are met: * + * * Redistributions of source code must retain the above copyright * + * notice, this list of conditions and the following disclaimer. * + * * Redistributions in binary form must reproduce the above copyright * + * notice, this list of conditions and the following disclaimer in * + * the documentation and/or other materials provided with the * + * distribution. * + * * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS * + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT * + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR * + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT * + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, * + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY * + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT * + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE * + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * + * + * Author: Maxim Ignatenko + * + * $FreeBSD$ + */ + +#ifndef _NETGRAPH_NG_PATCH_H_ +#define _NETGRAPH_NG_PATCH_H_ + +/* Node type name. */ +#define NG_PATCH_NODE_TYPE "patch" + +/* Node type cookie. */ +#define NGM_PATCH_COOKIE 1262445507 + +/* Hook names */ +#define NG_PATCH_HOOK_IN "in" +#define NG_PATCH_HOOK_OUT "out" + +/* Netgraph commands understood by this node type */ +enum { + NGM_PATCH_SETCONFIG = 1, + NGM_PATCH_GETCONFIG, +}; + +/* Patching modes */ +#define NG_PATCH_MODE_SET 1 +#define NG_PATCH_MODE_ADD 2 +#define NG_PATCH_MODE_SUB 3 +#define NG_PATCH_MODE_AND 4 +#define NG_PATCH_MODE_OR 5 +#define NG_PATCH_MODE_XOR 6 + +struct ng_patch_config { + uint32_t value; + uint32_t offset; + uint32_t length; /* 1,2 or 4 bytes */ + uint32_t mode; +}; + +#define NG_PATCH_CONFIG_TYPE_INFO { \ + { "value", &ng_parse_uint32_type }, \ + { "offset", &ng_parse_uint32_type }, \ + { "length", &ng_parse_uint32_type }, \ + { "mode", &ng_parse_uint32_type }, \ + { NULL } \ +} + +#endif /* _NETGRAPH_NG_PATCH_H_ */ From owner-freebsd-net@FreeBSD.ORG Tue Jan 12 00:12:11 2010 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 36EFF1065672 for ; Tue, 12 Jan 2010 00:12:11 +0000 (UTC) (envelope-from julian@elischer.org) Received: from utility-0.aerioconnect.net (utility-0.aerioconnect.net [216.240.32.11]) by mx1.freebsd.org (Postfix) with ESMTP id 054B88FC12 for ; Tue, 12 Jan 2010 00:12:10 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by utility-0.aerioconnect.net (8.13.1/8.13.1) with ESMTP id o0C0CAkE002741; Mon, 11 Jan 2010 16:12:10 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 2D3702D6010; Mon, 11 Jan 2010 16:12:10 -0800 (PST) Message-ID: <4B4BBE59.9010908@elischer.org> Date: Mon, 11 Jan 2010 16:12:09 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Maxim Ignatenko References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: ng_patch node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 00:12:11 -0000 Maxim Ignatenko wrote: > Hi, > I've written netgraph node able to modify arbitrary (8|16|32)-bit > unsigned integer in passing packets. Node applies one of =,+,-,&,| and > ^ operations to number at given offset. > Modification applied to each packet received on "in" hook. If "out" > hook is connected - resulting packets passed on it, otherwise - > returned back on "in" (for more easy use with ng_ipfw). Packets > received on "out" hook passed on "in" unmodified. > Node supports two control messages: "getconfig" and "setconfig". > Configuration represented in next structure: > struct ng_patch_config { > uint32_t value; /* argument passed to requested operation */ > uint32_t offset; /* offset in bytes */ > uint32_t length; /* 1,2 or 4 bytes */ > uint32_t mode; /* operation code: 1 - "=", 2 - "+", 3 - > "-", 4 - "&", 5 - "|", 6 - "^" */ > }; > Same names used in ASCII representation. > > I wanted to make ipfw able to modify TTL and ToS fields in IP packets, > but after some generalization idea looked like described above. I like it :-) if you can provide a short man page, I can commit it for you. From owner-freebsd-net@FreeBSD.ORG Tue Jan 12 00:30:27 2010 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 51BD4106568D for ; Tue, 12 Jan 2010 00:30:27 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id D7E358FC0C for ; Tue, 12 Jan 2010 00:30:26 +0000 (UTC) Received: by bwz5 with SMTP id 5so14214680bwz.3 for ; Mon, 11 Jan 2010 16:30:19 -0800 (PST) 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 :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=hq7ewOlk81HVXT/PqU6iOs2uxWGNdCcDej8zgD6Re98=; b=t3+YF724HxPFl7fP5hCeQcRcJ5ib/Rad8yzcYdJ8zTUhe1i5pIz/j3TlGc0At+yylj Ih8kcUq28+0oynbfy7xaCk1UU4jd9AlWVYeNxv+V54pkNRn1llDOlQdz9c5G7oOrNgqZ K9gySjZLaKpvds+rrLujVZuy8q+599BXUH4Z0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=wvvllMv3qUpxfopfFjlY08HQPxjVlGLVqxi3wfcL/Q0v/y34Nvije0cvQsmoSYgJUm yFQHWbNKFfDoIPTLT78T0NTB4GpJ5Cm3sS6Yvf2dIclmxjSYZ5v7/xK6ce8j0awTVf/C Dol7Q2A7pG/+lTepjTqzRhfZn3i58gYUTnCwc= MIME-Version: 1.0 Received: by 10.204.135.217 with SMTP id o25mr1903114bkt.105.1263256219093; Mon, 11 Jan 2010 16:30:19 -0800 (PST) In-Reply-To: <4B4BBE59.9010908@elischer.org> References: <4B4BBE59.9010908@elischer.org> From: Maxim Ignatenko Date: Tue, 12 Jan 2010 02:29:59 +0200 Message-ID: To: Julian Elischer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: ng_patch node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 00:30:27 -0000 2010/1/12 Julian Elischer : > Maxim Ignatenko wrote: >> >> Hi, >> I've written netgraph node able to modify arbitrary (8|16|32)-bit >> unsigned integer in passing packets. Node applies one of =3D,+,-,&,| and >> ^ operations to number at given offset. >> Modification applied to each packet received on "in" hook. If "out" >> hook is connected - resulting packets passed on it, otherwise - >> returned back on "in" (for more easy use with ng_ipfw). Packets >> received on "out" hook passed on "in" unmodified. >> Node supports two control messages: "getconfig" and "setconfig". >> Configuration represented in next structure: >> struct ng_patch_config { >> =C2=A0 =C2=A0 =C2=A0 uint32_t =C2=A0 =C2=A0 =C2=A0 =C2=A0value; /* argum= ent passed to requested operation */ >> =C2=A0 =C2=A0 =C2=A0 uint32_t =C2=A0 =C2=A0 =C2=A0 =C2=A0offset; /* offs= et in bytes */ >> =C2=A0 =C2=A0 =C2=A0 uint32_t =C2=A0 =C2=A0 =C2=A0 =C2=A0length; /* 1,2 = or 4 bytes */ >> =C2=A0 =C2=A0 =C2=A0 uint32_t =C2=A0 =C2=A0 =C2=A0 =C2=A0mode; /* operat= ion code: 1 - "=3D", 2 - "+", 3 - >> "-", 4 - "&", 5 - "|", 6 - "^" */ >> }; >> Same names used in ASCII representation. >> >> I wanted to make ipfw able to modify TTL and ToS fields in IP packets, >> but after some generalization idea looked like described above. > > > I like it :-) > if you can provide a short man page, I can commit it for you. > I'll try to do this in few days, thanks :) From owner-freebsd-net@FreeBSD.ORG Tue Jan 12 00:45:22 2010 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 8E6451065725 for ; Tue, 12 Jan 2010 00:45:22 +0000 (UTC) (envelope-from swun2010@gmail.com) Received: from mail-pz0-f202.google.com (mail-pz0-f202.google.com [209.85.222.202]) by mx1.freebsd.org (Postfix) with ESMTP id 5E4098FC1A for ; Tue, 12 Jan 2010 00:45:22 +0000 (UTC) Received: by pzk40 with SMTP id 40so866827pzk.7 for ; Mon, 11 Jan 2010 16:45:14 -0800 (PST) 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 :content-transfer-encoding; bh=kFj9dLx0E6rsBJFU/3t7ikUZOwXjWLg1O2Mtrv0ZaNc=; b=F7sx1mzUWYxqeyA8fmOs2j/2RBVKEbVw7wHCeUshy6MRVs7lot+6IrjX2PGbxBPn+A vQLFgEPcn0t38MhOVLtJL/fzjFP0teMMEPJC9P6s6msurI+e0ky/Wns1kuU+vf0HZ6Zb u9rzKYhzUlyyMgISNw8ow25xTVWrlsDWY0VT4= 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:content-transfer-encoding; b=MRF67w5YHPGipwtVcV7iMk9f8H0biuuwMhXotgiq7yOYHfjvGQ4JNHhW6SDonKZmlM VEuPgj3+wzbAonhrJHqHfI48iAuty7qR8LKnoxjtWYMHnV1Te4gYuO7wzHcSktyDKs5X 80WJBSh59OGCbY77l0z/noWJEaNM+6Z55yhX4= MIME-Version: 1.0 Received: by 10.141.214.27 with SMTP id r27mr9653931rvq.286.1263257114646; Mon, 11 Jan 2010 16:45:14 -0800 (PST) In-Reply-To: References: <736c47cb1001102049v71757b78oe954fd39f9d03118@mail.gmail.com> Date: Tue, 12 Jan 2010 11:45:14 +1100 Message-ID: <736c47cb1001111645v41e87672i201493ece1eb4ab0@mail.gmail.com> From: Sam Wun To: Gavin Atkinson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: freebsd for Sun Fire X4250 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, 12 Jan 2010 00:45:22 -0000 Hi Gavin, The reason I want to stick with i386 is because about few years ago when I tried AMD release of FreeBSD, it didn't have the same level of proficiency as i386 release of FreeBSD - packagThat was my impression at that time. I hope it has changed in this years. Is there any major installation difference between AMD (64) and i386 release of FreeBSD (8.0)? Thank you for your answers. Sam On Tue, Jan 12, 2010 at 10:05 AM, Gavin Atkinson wrote: > On Mon, 11 Jan 2010, Sam Wun wrote: >> This server is built with Xeon cpu processor, Intel based. >> Can FreeBSD 8+ fully compatible with this server like those ordinary >> Intel i386 machine? > > Although it's hard to say (the Sun website doesn't realy give enough spec > details), I'd be surprised if it doesn't work. =A0FreeBSD runs very nicel= y > on every Intel- and amd64-based Sun machine I've tried it on. > > You'll almost certainly want to use the FreeBSD amd64 release rather than > i386, and I'd probably recommend 8.0-RELEASE, although 7.2 should work > fine. > > By the way, this is the wrong list for questions like this: if you have > any others, you're probably best off directing them to > freebsd-questions@FreeBSD.org > > Gavin > From owner-freebsd-net@FreeBSD.ORG Tue Jan 12 01:10:04 2010 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 16AD31065676 for ; Tue, 12 Jan 2010 01: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 E1B248FC19 for ; Tue, 12 Jan 2010 01:10:03 +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 o0C1A3Ic067874 for ; Tue, 12 Jan 2010 01: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 o0C1A3bf067873; Tue, 12 Jan 2010 01:10:03 GMT (envelope-from gnats) Date: Tue, 12 Jan 2010 01:10:03 GMT Message-Id: <201001120110.o0C1A3bf067873@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Jaz Cc: Subject: Re: kern/134079: [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8.0) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jaz List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 01:10:04 -0000 The following reply was made to PR kern/134079; it has been noted by GNATS. From: Jaz To: bug-followup@FreeBSD.org, g.zhengming@gmail.com Cc: Subject: Re: kern/134079: [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8.0) Date: Tue, 12 Jan 2010 11:32:22 +1100 I have the same problem since upgrading from 7.2 to 8.0. I have a PCI Intel 1000 card. Perhaps someone could make a patch that does what Korba has done? From owner-freebsd-net@FreeBSD.ORG Tue Jan 12 01:12:45 2010 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 50817106568D for ; Tue, 12 Jan 2010 01:12:45 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 276E58FC1F for ; Tue, 12 Jan 2010 01:12:45 +0000 (UTC) Received: by pxi12 with SMTP id 12so14932960pxi.3 for ; Mon, 11 Jan 2010 17:12:42 -0800 (PST) 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 :content-transfer-encoding; bh=bvln8zhNuvv5Fd9OxsoMF5dbkviK5IRcGQ3JG+Ix10A=; b=fbJUxJbvdeWxoejQhrvEgtJlwhutf1Lk42+WWBluEczKwPfAqchfLJCTp94A3rYZTO 09Z7MC5bmB/FsaSsIb175dVKtQ41/0Lcheh1f2W8KkkPrd4RaZsV3kWKIqsixjUG1hXg 6JTD7waX4W50oDD87I9K6pIws3OvRFCVl5GoE= 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:content-transfer-encoding; b=d3Vs4ecYwLHp/zmiWzPFCR0SuxbnqMW/ioniCYqJzkZi5wLleFNQRkaGyzcea/9ALa DgTmgatIuU4RmrGGOCTbSDKWbI4qe2HSyfbFvNQrmsK0wnRGnwK8m80fzoHd/nwoHFOT tfD409IMiTbxaMoiD9+mH7giZfz0LcLfUBIjo= MIME-Version: 1.0 Received: by 10.142.67.7 with SMTP id p7mr2996562wfa.251.1263258762344; Mon, 11 Jan 2010 17:12:42 -0800 (PST) In-Reply-To: <201001120110.o0C1A3bf067873@freefall.freebsd.org> References: <201001120110.o0C1A3bf067873@freefall.freebsd.org> Date: Mon, 11 Jan 2010 19:12:42 -0600 Message-ID: <11167f521001111712m713c1721i3fb239c60c6c94f3@mail.gmail.com> From: "Sam Fourman Jr." To: Jaz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: kern/134079: [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8.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: Tue, 12 Jan 2010 01:12:45 -0000 On Mon, Jan 11, 2010 at 7:10 PM, Jaz wrote: > The following reply was made to PR kern/134079; it has been noted by GNAT= S. > > From: Jaz > To: bug-followup@FreeBSD.org, g.zhengming@gmail.com > Cc: > Subject: Re: kern/134079: [em] "em0: Invalid MAC address" in FreeBSD-Curr= ent ( > =A0 =A0 =A0 =A08.0) > Date: Tue, 12 Jan 2010 11:32:22 +1100 > > =A0I have the same problem since upgrading from 7.2 to 8.0. I have a PCI > =A0Intel 1000 card. > > =A0Perhaps someone could make a patch that does what Korba has done? Try 9 Current, I had the same problem with a Fibre em(4) card and I build a -CURRENT kernel last week and it worked Sam Fourman Jr. From owner-freebsd-net@FreeBSD.ORG Tue Jan 12 01:44:53 2010 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 A2F46106568B for ; Tue, 12 Jan 2010 01:44:53 +0000 (UTC) (envelope-from pschmehl_lists@tx.rr.com) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.122]) by mx1.freebsd.org (Postfix) with ESMTP id 641708FC0A for ; Tue, 12 Jan 2010 01:44:53 +0000 (UTC) Received: from cdptpa-omtalb.mail.rr.com ([10.127.143.52]) by cdptpa-qmta01.mail.rr.com with ESMTP id <20100112013129905.WPNB16905@cdptpa-qmta01.mail.rr.com> for ; Tue, 12 Jan 2010 01:31:29 +0000 X-Authority-Analysis: v=1.0 c=1 a=6I5d2MoRAAAA:8 a=itVrKB2XG0UfzXXN2_oA:9 a=uKnG9PXvExcL3SnBUz0A:7 a=_W2K1IMK2WLSigQHx5MUG6wTZMcA:4 a=SV7veod9ZcQA:10 X-Cloudmark-Score: 0 X-Originating-IP: 76.184.157.127 Received: from [76.184.157.127] ([76.184.157.127:54494] helo=[10.0.0.3]) by cdptpa-oedge02.mail.rr.com (envelope-from ) (ecelerity 2.2.2.39 r()) with ESMTP id A3/26-19471-3B0DB4B4; Tue, 12 Jan 2010 01:30:27 +0000 Date: Mon, 11 Jan 2010 19:30:28 -0600 From: Paul Schmehl To: Gavin Atkinson , Sam Wun Message-ID: <3909AEA610D981D9C08188FA@Macintosh-2.local> In-Reply-To: References: <736c47cb1001102049v71757b78oe954fd39f9d03118@mail.gmail.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-net@FreeBSD.org Subject: Re: freebsd for Sun Fire X4250 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Paul Schmehl List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 01:44:53 -0000 We have a SunFire 420 running amd64 FreeBSD release 7.2. I doubt you will have a problem. --On January 11, 2010 5:05:04 PM -0600 Gavin Atkinson wrote: > > On Mon, 11 Jan 2010, Sam Wun wrote: >> This server is built with Xeon cpu processor, Intel based. >> Can FreeBSD 8+ fully compatible with this server like those ordinary >> Intel i386 machine? > > Although it's hard to say (the Sun website doesn't really give enough spec > details), I'd be surprised if it doesn't work. FreeBSD runs very nicely > on every Intel- and amd64-based Sun machine I've tried it on. > > You'll almost certainly want to use the FreeBSD amd64 release rather than > i386, and I'd probably recommend 8.0-RELEASE, although 7.2 should work > fine. > > By the way, this is the wrong list for questions like this: if you have > any others, you're probably best off directing them to > freebsd-questions@FreeBSD.org > > Gavin > _______________________________________________ > 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" Paul Schmehl, If it isn't already obvious, my opinions are my own and not those of my employer. ****************************************** WARNING: Check the headers before replying From owner-freebsd-net@FreeBSD.ORG Tue Jan 12 04:56:34 2010 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 A7C63106566C for ; Tue, 12 Jan 2010 04:56:34 +0000 (UTC) (envelope-from gigabyte.tmn@gmail.com) Received: from mail-ew0-f213.google.com (mail-ew0-f213.google.com [209.85.219.213]) by mx1.freebsd.org (Postfix) with ESMTP id 351C88FC12 for ; Tue, 12 Jan 2010 04:56:33 +0000 (UTC) Received: by ewy5 with SMTP id 5so11398858ewy.14 for ; Mon, 11 Jan 2010 20:56:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:reply-to:from:to :references:subject:date:organization:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole; bh=Wac6NEXK/KI2xi1+vSXMKtEzw75a6zTDFWMCXUlRVsU=; b=eujiMsvOVD8VAjLwPtbqS1hvuZMhpUtOEj/Rf3klvnmeiLYYuYHehRURC8vgc8Paha nn/y3CKBEhzqy6Ln3Zye4mLkf4C1ssIyC+8rLkeENsph0MwMiHtJifcTdYlwCGg7K55d Qz+IUEbInDajq6B8u5l6s/XXCxDZfssybBNnk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:reply-to:from:to:references:subject:date:organization :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:x-mailer:x-mimeole; b=Wt/FgdPhHdFbEv3qxnYlDUtgzQ+GFMVu7qWIh2oGNM51euUNa80EVzUNxja2VTaqt4 nxt03kmrRoTZXN5bI/QmviUcgs2NDqhlTJojBh2hWeZmqDBuzJ75DPfYVkCcyGrjgxl3 W3uYA4fKYkzlNqhNxm1X8ItLkJ+9WERtnMFW8= Received: by 10.213.110.206 with SMTP id o14mr7572619ebp.6.1263272184292; Mon, 11 Jan 2010 20:56:24 -0800 (PST) Received: from dm ([91.211.192.210]) by mx.google.com with ESMTPS id 23sm7656542eya.35.2010.01.11.20.56.21 (version=SSLv3 cipher=RC4-MD5); Mon, 11 Jan 2010 20:56:22 -0800 (PST) Message-ID: From: "Dmitriy Zamuraev" To: References: Date: Tue, 12 Jan 2010 09:56:21 +0500 Organization: Netline NSP MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5503 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5503 Subject: Re: ng_patch node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dmitriy Zamuraev List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 04:56:34 -0000 > Hi, > I've written netgraph node able to modify arbitrary (8|16|32)-bit > unsigned integer in passing packets. Node applies one of =,+,-,&,| and > ^ operations to number at given offset. Thank you. I think about more functionality... From owner-freebsd-net@FreeBSD.ORG Tue Jan 12 05:24:59 2010 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 9CCB0106566C for ; Tue, 12 Jan 2010 05:24:59 +0000 (UTC) (envelope-from callumgibson@optusnet.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id 349EE8FC18 for ; Tue, 12 Jan 2010 05:24:58 +0000 (UTC) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o0C3PwVQ007537 for ; Tue, 12 Jan 2010 14:25:58 +1100 Received: from omma.gibson.athome (c122-106-69-195.rivrw1.nsw.optusnet.com.au [122.106.69.195]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with SMTP id o0C3Ptw1003860 for ; Tue, 12 Jan 2010 14:25:55 +1100 Received: (qmail 42466 invoked by uid 107); 12 Jan 2010 14:25:55 +1100 Date: 12 Jan 2010 14:25:55 +1100 Date: Tue, 12 Jan 2010 14:25:55 +1100 From: Callum Gibson To: freebsd-net@freebsd.org Message-ID: <20100112032554.GA40871@omma.gibson.athome> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: lagg doesn't fail back to master 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, 12 Jan 2010 05:24:59 -0000 Hi all, I've sucessfully setup a lagg0 interface on my laptop to fail the wired connection over to wireless when it's unplugged. I have the following in my rc.conf: wlans_bwi0="wlan0" ifconfig_bwi0="ether XXX" ifconfig_wlan0="WPA mode 11g" cloned_interfaces="lagg0" ifconfig_lagg0="SYNCDHCP laggproto failover laggport bge0 laggport wlan0" This seems to work fine at boot. However, once I plug wired back in, lagg doesn't switch back to the master. Here is what ifconfig is showing: bge0: flags=8802 metric 0 mtu 1500 options=9b ether XXX media: Ethernet autoselect (100baseTX ) status: active bwi0: flags=8843 metric 0 mtu 2290 ether XXX media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated wlan0: flags=8843 metric 0 mtu 1500 ether XXX media: IEEE 802.11 Wireless Ethernet OFDM/24Mbps mode 11g status: associated ssid 47FifthSt channel 6 (2437 Mhz 11g) bssid 00:0f:66:4f:1c:b8 country US authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit txpower 0 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS roaming MANUAL lagg0: flags=8843 metric 0 mtu 1500 ether XXX inet 192.168.1.4 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect status: active laggproto failover laggport: wlan0 flags=4 laggport: bge0 flags=1 The handbook says lagg should switch back to master when it becomes active again. I tried a few other things like taking wlan0 down manually and even stopping the interface and restarting lagg without wlan active, but this just hung my network connection. Even destroying lagg and recreating by hand had no effect and lagg0 came back with the children already attached (as seen above) so the system is caching that information somewhere and lagg just won't let go of wlan... I'm on 8.0-STABLE from about 4 Dec 2009. Any ideas? regards, Callum -- Callum Gibson @ home http://members.optusnet.com.au/callumgibson/ From owner-freebsd-net@FreeBSD.ORG Tue Jan 12 05:37:01 2010 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 4A8D81065676 for ; Tue, 12 Jan 2010 05:37:01 +0000 (UTC) (envelope-from julian@elischer.org) Received: from utility-0.aerioconnect.net (utility-0.aerioconnect.net [216.240.32.11]) by mx1.freebsd.org (Postfix) with ESMTP id 174138FC21 for ; Tue, 12 Jan 2010 05:37:00 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by utility-0.aerioconnect.net (8.13.1/8.13.1) with ESMTP id o0C5b0aY014299; Mon, 11 Jan 2010 21:37:00 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 3103E2D6012; Mon, 11 Jan 2010 21:37:00 -0800 (PST) Message-ID: <4B4C0A7B.2020306@elischer.org> Date: Mon, 11 Jan 2010 21:36:59 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dmitriy Zamuraev References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: ng_patch node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 05:37:01 -0000 Dmitriy Zamuraev wrote: >> Hi, >> I've written netgraph node able to modify arbitrary (8|16|32)-bit >> unsigned integer in passing packets. Node applies one of =,+,-,&,| and >> ^ operations to number at given offset. have an IP version that corrects the checksums as you fiddle bytes. juat an idea > > Thank you. > I think about more functionality... > _______________________________________________ > 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 Jan 12 06:19:36 2010 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 C794A106568F; Tue, 12 Jan 2010 06:19:36 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 7B98B8FC12; Tue, 12 Jan 2010 06:19:36 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id o0C6IKjE002392; Tue, 12 Jan 2010 00:18:20 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id o0C6IJd3002391; Tue, 12 Jan 2010 00:18:19 -0600 (CST) (envelope-from brooks) Date: Tue, 12 Jan 2010 00:18:19 -0600 From: Brooks Davis To: Artis Caune Message-ID: <20100112061819.GA2135@lor.one-eyed-alien.net> References: <4AE852C1.8090103@keff.org> <20091028164330.GA71430@lor.one-eyed-alien.net> <9e20d71e0910281531o56d82709ife0b76a59bff5f23@mail.gmail.com> <20091029000822.GA74744@lor.one-eyed-alien.net> <9e20d71e0910290217k58493c3enb7dc303f50385533@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline In-Reply-To: <9e20d71e0910290217k58493c3enb7dc303f50385533@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Tue, 12 Jan 2010 00:18:20 -0600 (CST) Cc: Sebastian Hyrwall , freebsd-net@freebsd.org, Brooks Davis Subject: Re: Hi. Regarding "automatic vlan creation" 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, 12 Jan 2010 06:19:36 -0000 --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 29, 2009 at 11:17:27AM +0200, Artis Caune wrote: > 2009/10/29 Brooks Davis : > >> btw, wouldn't it be nice not to bother with loader.conf when using > >> . syntax? > >> This patch will load if_vlan automatically in this case: > > > > Sorry but my reation is: eww. ??There's no way I'd commit that. ??You'd= be > > randomly loading the vlan code for any interface that had a dot in it. >=20 > You are right, forgot about 'ifconfig rename'. >=20 > > The real change we should make it to add device vlan to GENERIC. ??It's > > long past time for it to be in by default. >=20 > It's even better, what's need to be done to move it to GENERIC? It took me longer than I'd hoped, but I've added vlan to GENERIC in HEAD, RELENG_8, and RELENG_7 so it will be there 7.3 and 8.1. -- Brooks --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFLTBQqXY6L6fI4GtQRAs9iAJ9Pmh01ktuEW81QUD6U3KEOWbH5gQCfc0A5 /fPcksFOmVhj3BbZZRilj3U= =Kiwp -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- From owner-freebsd-net@FreeBSD.ORG Tue Jan 12 06:40:02 2010 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 8AE421065679 for ; Tue, 12 Jan 2010 06: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 6057D8FC08 for ; Tue, 12 Jan 2010 06:40:02 +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 o0C6e2TS063178 for ; Tue, 12 Jan 2010 06:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0C6e2IN063172; Tue, 12 Jan 2010 06:40:02 GMT (envelope-from gnats) Date: Tue, 12 Jan 2010 06:40:02 GMT Message-Id: <201001120640.o0C6e2IN063172@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Kevin Dorne Cc: Subject: Re: bin/142547: wpa_supplicant(8) drops connection on key renegotiation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kevin Dorne List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 06:40:02 -0000 The following reply was made to PR bin/142547; it has been noted by GNATS. From: Kevin Dorne To: bug-followup@FreeBSD.org Cc: Subject: Re: bin/142547: wpa_supplicant(8) drops connection on key renegotiation Date: Mon, 11 Jan 2010 22:16:46 -0800 The same behavior occurs with the SVN driver. From owner-freebsd-net@FreeBSD.ORG Tue Jan 12 07:06:52 2010 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 E8E8A1065670 for ; Tue, 12 Jan 2010 07:06:52 +0000 (UTC) (envelope-from pz-freebsd-net@ziemba.us) Received: from ziemba.us (208-106-105-148.dsl.static.sonic.net [208.106.105.148]) by mx1.freebsd.org (Postfix) with ESMTP id C0EF98FC08 for ; Tue, 12 Jan 2010 07:06:52 +0000 (UTC) Received: from hairball.ziemba.us (localhost.ziemba.us [127.0.0.1]) by hairball.ziemba.us (8.14.3/8.14.3) with ESMTP id o0C76qhH007554 for ; Mon, 11 Jan 2010 23:06:52 -0800 (PST) (envelope-from pz-freebsd-net@ziemba.us) Received: (from mailnull@localhost) by hairball.ziemba.us (8.14.3/8.14.3/Submit) id o0C76qU3007553 for freebsd-net@freebsd.org; Mon, 11 Jan 2010 23:06:52 -0800 (PST) (envelope-from pz-freebsd-net@ziemba.us) X-Authentication-Warning: hairball.ziemba.us: mailnull set sender to pz-freebsd-net@ziemba.us using -f Received: (from news@localhost) by hairball.ziemba.us (8.14.3/8.14.3/Submit) id o0C76pRU007519 for treehouse-mail-freebsd-net@hairball.treehouse.napa.ca.us; Mon, 11 Jan 2010 23:06:51 -0800 (PST) (envelope-from news) From: "G. Paul Ziemba" To: freebsd-net@freebsd.org Date: Tue, 12 Jan 2010 07:06:51 +0000 (UTC) Message-id: References: <4B461646.8090508@elischer.org> Errors-to: "G. Paul Ziemba" Subject: Re: vimage vs. ipfilter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: paul+usenet@w6yx.stanford.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 07:06:53 -0000 julian@elischer.org (Julian Elischer) writes: >[vimage compatibility in 8.0] >ipfw is, (experimentally) and pf has patches to make it so. Thanks for your reply (and for your vimage efforts). I'd like to try vimage + pf and searched for the patch (including freebsd-pf and freebsd-virtualization list archives) but couldn't find it. Do you have a pointer? thanks, ~!paul -- G. Paul Ziemba FreeBSD unix: 11:06PM up 29 days, 47 mins, 26 users, load averages: 0.21, 0.20, 0.21 From owner-freebsd-net@FreeBSD.ORG Tue Jan 12 07:25:11 2010 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 0A2501065670 for ; Tue, 12 Jan 2010 07:25:11 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 945D98FC08 for ; Tue, 12 Jan 2010 07:25:10 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 97CDB41C707; Tue, 12 Jan 2010 08:25:09 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id sAi2tjzzKTFS; Tue, 12 Jan 2010 08:25:08 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id A814F41C6DB; Tue, 12 Jan 2010 08:25:08 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id EC2A54448EC; Tue, 12 Jan 2010 07:23:18 +0000 (UTC) Date: Tue, 12 Jan 2010 07:23:18 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: paul+usenet@w6yx.stanford.edu In-Reply-To: Message-ID: <20100112072234.B50938@maildrop.int.zabbadoz.net> References: <4B461646.8090508@elischer.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: vimage vs. ipfilter 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, 12 Jan 2010 07:25:11 -0000 On Tue, 12 Jan 2010, G. Paul Ziemba wrote: > julian@elischer.org (Julian Elischer) writes: > >> [vimage compatibility in 8.0] >> ipfw is, (experimentally) and pf has patches to make it so. > > Thanks for your reply (and for your vimage efforts). > > I'd like to try vimage + pf and searched for the patch (including > freebsd-pf and freebsd-virtualization list archives) but couldn't > find it. Do you have a pointer? I am not sure if a patch was published but you should be able to find the code to update pf and add V_support at: http://svn.freebsd.org/viewvc/base/user/eri/ /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-net@FreeBSD.ORG Tue Jan 12 07:26:41 2010 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 B2CC6106566B for ; Tue, 12 Jan 2010 07:26:41 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 42D308FC12 for ; Tue, 12 Jan 2010 07:26:40 +0000 (UTC) Received: by fxm27 with SMTP id 27so103959fxm.3 for ; Mon, 11 Jan 2010 23:26:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=mf0IDmMrKbgPItwqSFnzILElYhC9JpkFpc3pz+EVIQw=; b=TTbxHYVLPZk5NTcg1FOLg2vGVzN0zzwfiZxb0rJHeT+k8DFzAMXeuTpcV5d/6UFOpY FH4YPPjKJMBSMi5ryZUUyerWeT4dXmszfSNTLyYOaHWjJpU2aoWDqShOJb4RIMUkA7gz /3Y2L+kDdAtsXZQ8i8fgAiVhwlY2sjeYtm0So= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=MT3cs/9oaWfN0cRFqQfnmlyq7gTm3AVLvmbpGFKhsL+BBRZC2jC8FMkgrgkGD4RO1E eNxyLOu05TehRWiSjGZ9jrbTuAaN75HLh8pwmt/0I6mQqXXvllhV2ZOatFXKjHVHWP2I blNhKYt/NvSwXF8MHYaDiWRi0kDu3AvEJl1OU= Received: by 10.223.5.87 with SMTP id 23mr9548479fau.87.1263281191717; Mon, 11 Jan 2010 23:26:31 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 14sm10056093fxm.7.2010.01.11.23.26.30 (version=SSLv3 cipher=RC4-MD5); Mon, 11 Jan 2010 23:26:31 -0800 (PST) Sender: Alexander Motin Message-ID: <4B4C2425.2010402@FreeBSD.org> Date: Tue, 12 Jan 2010 09:26:29 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Maxim Ignatenko References: <1263262983.00205781.1263251401@10.7.7.3> In-Reply-To: <1263262983.00205781.1263251401@10.7.7.3> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: ng_patch node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 07:26:41 -0000 Maxim Ignatenko wrote: > I've written netgraph node able to modify arbitrary (8|16|32)-bit > unsigned integer in passing packets. Node applies one of =,+,-,&,| and > ^ operations to number at given offset. > Modification applied to each packet received on "in" hook. If "out" > hook is connected - resulting packets passed on it, otherwise - > returned back on "in" (for more easy use with ng_ipfw). Packets > received on "out" hook passed on "in" unmodified. > Node supports two control messages: "getconfig" and "setconfig". > Configuration represented in next structure: > struct ng_patch_config { > uint32_t value; /* argument passed to requested operation */ > uint32_t offset; /* offset in bytes */ > uint32_t length; /* 1,2 or 4 bytes */ > uint32_t mode; /* operation code: 1 - "=", 2 - "+", 3 - > "-", 4 - "&", 5 - "|", 6 - "^" */ > }; > Same names used in ASCII representation. > > I wanted to make ipfw able to modify TTL and ToS fields in IP packets, > but after some generalization idea looked like described above. > > Next patch made against 8-STABLE r200201 Just few stones into your garden: > + if (((struct ng_patch_config *)msg->data)->offset < 0) > + error = EINVAL; As I see, offset field is unsigned there. > + case 4: > + *((uint32_t *)dst) += > priv->value4; I think such dereference may crash archs with strong alignment requirements. m_copydata/m_copyback could do it possibly slower, but safer and wouldn't require m_pullup. Also result of such multi-byte operations is endian-dependent. I would be nice to do hton/ntoh somewhere. Also, what's about checksums? -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Tue Jan 12 09:52:06 2010 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 DE1131065676; Tue, 12 Jan 2010 09:52:06 +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 B5EFD8FC1E; Tue, 12 Jan 2010 09:52:06 +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 o0C9q6xY062024; Tue, 12 Jan 2010 09:52:06 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0C9q6Ic062020; Tue, 12 Jan 2010 09:52:06 GMT (envelope-from gavin) Date: Tue, 12 Jan 2010 09:52:06 GMT Message-Id: <201001120952.o0C9q6Ic062020@freefall.freebsd.org> To: kaduk@mit.edu, gavin@FreeBSD.org, freebsd-net@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock 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, 12 Jan 2010 09:52:06 -0000 Synopsis: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock State-Changed-From-To: open->closed State-Changed-By: gavin State-Changed-When: Tue Jan 12 09:50:39 UTC 2010 State-Changed-Why: Submitter reports that this is now fixed. http://www.freebsd.org/cgi/query-pr.cgi?pr=140036 From owner-freebsd-net@FreeBSD.ORG Tue Jan 12 16:24:48 2010 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 B1068106566B for ; Tue, 12 Jan 2010 16:24:48 +0000 (UTC) (envelope-from jahuttun@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 53FE78FC19 for ; Tue, 12 Jan 2010 16:24:47 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 22so23905fge.13 for ; Tue, 12 Jan 2010 08:24:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.85.132 with SMTP id u4mr674551wee.191.1263313478555; Tue, 12 Jan 2010 08:24:38 -0800 (PST) In-Reply-To: <4B474F89.9020108@mahan.org> References: <4cd8d14e1001080238yfc2ee4cx6f261aa94f79a246@mail.gmail.com> <4B474F89.9020108@mahan.org> Date: Tue, 12 Jan 2010 18:24:38 +0200 Message-ID: <4cd8d14e1001120824s6e70e29fm60a71ebdac21e131@mail.gmail.com> From: Janne Huttunen To: Patrick Mahan Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: Anon port selection 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, 12 Jan 2010 16:24:48 -0000 > > Then when the second process in in_pcbbind_setup() tries > > to check if the port is already in use, it won't match > > the INADDR_ANY and assigns the same port again. > > Well it has been almost 20 years since I first ran across > this issue and was told back then that it was "as designed". May be, but it sure feels unintuitive to me. Besides, as far as I can tell, NetBSD (5.0.1) doesn't do it, OpenBSD (4.6) doesn't do it, Linux (2.6.31) doesn't do it and FreeBSD with the attached patch doesn't do it. Whether or not this change breaks something else is another story. --- in_pcb.c.orig 2010-01-12 16:47:57.000000000 +0200 +++ in_pcb.c 2010-01-12 16:50:18.000000000 +0200 @@ -800,6 +800,12 @@ in_pcbconnect_setup(struct inpcb *inp, s faddr = sin->sin_addr; fport = sin->sin_port; + if (lport == 0) { + error = in_pcbbind_setup(inp, NULL, &laddr.s_addr, &lport, + cred); + if (error) + return (error); + } if (!TAILQ_EMPTY(&V_in_ifaddrhead)) { /* * If the destination address is INADDR_ANY, @@ -864,12 +870,6 @@ in_pcbconnect_setup(struct inpcb *inp, s *oinpp = oinp; return (EADDRINUSE); } - if (lport == 0) { - error = in_pcbbind_setup(inp, NULL, &laddr.s_addr, &lport, - cred); - if (error) - return (error); - } *laddrp = laddr.s_addr; *lportp = lport; *faddrp = faddr.s_addr; From owner-freebsd-net@FreeBSD.ORG Tue Jan 12 21:36:07 2010 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 99DDB106568D for ; Tue, 12 Jan 2010 21:36:07 +0000 (UTC) (envelope-from Brett.Lee@Sun.COM) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by mx1.freebsd.org (Postfix) with ESMTP id 690608FC41 for ; Tue, 12 Jan 2010 21:36:07 +0000 (UTC) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o0CLa77l015278 for ; Tue, 12 Jan 2010 21:36:07 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KW500D00KA6JM00@mail-amer.sun.com> for freebsd-net@freebsd.org; Tue, 12 Jan 2010 14:36:07 -0700 (MST) Received: from [192.168.1.11] ([unknown] [10.80.64.1]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KW5000AMLC4P300@mail-amer.sun.com> for freebsd-net@freebsd.org; Tue, 12 Jan 2010 14:36:04 -0700 (MST) Date: Tue, 12 Jan 2010 14:36:01 -0700 From: Brett Lee Sender: Brett.Lee@Sun.COM To: freebsd-net@freebsd.org Message-id: <4B4CEB41.3000805@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Subject: How to enable IPv6 on a subset of interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 21:36:07 -0000 Hello, Using FreeBSD 8.0-RELEASE, and am trying variations in /etc/rc.conf in an attempt to enable IPv6 on ONLY one of the systems two interfaces. Specifically, em0 should be enabled IPv4 DHCP, and bge0 should be enabled IPv6 only. From the KAME link below, and the files /etc/network.subr and /etc/defaults/rc.conf, am reading that "ipv6_network_interface" should work; however the following still results in em0 obtaining IPv6 addresses: http://www.kame.net/~suz/freebsd-ipv6-config-guide.txt ifconfig_em0="DHCP" ipv6_enable="YES" ipv6_network_interface="bge0" ipv6_network_interfaces="bge0" In another attempt (see link below), it looks like "ifconfig_em0" may support a "NOIPV6" param, but in practice it doesn't seem to work for me: http://lists.freebsd.org/pipermail/freebsd-rc/2007-May/001106.html ifconfig_em0="DHCP NOIPV6" ipv6_enable="YES" #ipv6_network_interface="bge0" #ipv6_network_interfaces="bge0" Am hopeful that someone might point out how I could enable this configuration. Thanks in advance! -Brett From owner-freebsd-net@FreeBSD.ORG Wed Jan 13 00:42:07 2010 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 0B7481065672 for ; Wed, 13 Jan 2010 00:42:07 +0000 (UTC) (envelope-from dhorn2000@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 60CE38FC1E for ; Wed, 13 Jan 2010 00:42:06 +0000 (UTC) Received: by fxm27 with SMTP id 27so72699fxm.3 for ; Tue, 12 Jan 2010 16:42:00 -0800 (PST) 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 :content-transfer-encoding; bh=+bHO/CoObBUnSvyvCnejgzUO3r2rR+/VnRTo5U2LHXU=; b=meNlB3UO2hBrLPoZuCcGHkHC/IQvk9WqHeKpThrUh7m+7cQSoZZURvKblTff3Tw0o/ AFCsO6BV2vxsVfeoNE9hrLA6dPHeqvsIkAc1I9453uRb4VxQhvcvaBs7cNMGmQxN5aHd 0vJH6QGEoSzYue2yEjzI74hEINQD0G2gn1UGk= 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:content-transfer-encoding; b=Tj5/kAV6zU0gZ8OLeYyEVOabZIF1kUiJYznVuH3d0hZAii95XHcDlo+1p3VJKn48T5 6O892AgORNjApOea7O199WHKfkeED7cupXcCkbzbfJJLqiUnY3sjxFwJUDTcFZEu60H5 chFKDqomNFdxqSzHFX5dWRxILPLdXMTbUILOw= MIME-Version: 1.0 Received: by 10.239.160.7 with SMTP id a7mr2495836hbd.98.1263343320610; Tue, 12 Jan 2010 16:42:00 -0800 (PST) In-Reply-To: <4B4CEB41.3000805@Sun.COM> References: <4B4CEB41.3000805@Sun.COM> Date: Tue, 12 Jan 2010 19:42:00 -0500 Message-ID: <25ff90d61001121642l7ac1de26ma7033ca997d90183@mail.gmail.com> From: David Horn To: Brett Lee Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: How to enable IPv6 on a subset of interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 00:42:07 -0000 On Tue, Jan 12, 2010 at 4:36 PM, Brett Lee wrote: > Hello, > > Using FreeBSD 8.0-RELEASE, and am trying variations in /etc/rc.conf in an > attempt to enable IPv6 on ONLY one of the systems two interfaces. > > Specifically, em0 should be enabled IPv4 DHCP, and bge0 should be enabled > IPv6 only. > > From the KAME link below, and the files /etc/network.subr and > /etc/defaults/rc.conf, am reading that "ipv6_network_interface" should wo= rk; > however the following still results in em0 obtaining IPv6 addresses: > > http://www.kame.net/~suz/freebsd-ipv6-config-guide.txt > > ifconfig_em0=3D"DHCP" > ipv6_enable=3D"YES" > ipv6_network_interface=3D"bge0" > ipv6_network_interfaces=3D"bge0" > > In another attempt (see link below), it looks like "ifconfig_em0" may > support a "NOIPV6" param, but in practice it doesn't seem to work for me: > > http://lists.freebsd.org/pipermail/freebsd-rc/2007-May/001106.html > > ifconfig_em0=3D"DHCP NOIPV6" > ipv6_enable=3D"YES" > #ipv6_network_interface=3D"bge0" > #ipv6_network_interfaces=3D"bge0" > > Am hopeful that someone might point out how I could enable this > configuration. > > Thanks in advance! =A0-Brett NOIPV6 is not a valid rc.conf configuration token at this time. I am assuming that you are using SLAAC for IPv6 prefix/address distribution (via rtadvd/radvd), and not DHCPv6. ipv6_network_interfaces is the correct rc.conf(5) variable to use to specifically control which interface gets configured using SLAAC via rtsol(8), but will not stop other interfaces from getting the RA (Router Advertisement) packet which starts IPv6 SLAAC (Stateless Autoconfiguration). In -current/9.0 there are nice new ifconfig parameters (inet6 ifdisabled -nud -accept_rtadv) and rc.conf variables that do just what you are looking for, but they are not in 8.0 at this time. In 8.0 you can use the ndp(8) utility to set the -accept_rtadv (and/or ifdisabled/nud,etc.) flags on a per-interface basis. The "-accept_rtadv" flag will disable SLAAC for the specified interface, but must be called before the interface gets the "RA" packet to be effective. You can do an ugly *unsupported hack* in 8.0 to call ndp from within rc.conf/rc.d startup scripts until the new code makes it into a release: ipv6_enable=3D"YES" ipv6_network_interfaces=3D"bge0" ifconfig_em0=3D"DHCP `ndp -i em0 ifdisabled -nud -accept_rtadv >/dev/null 2= >&1`" ifconfig_bge0=3D"UP" This will cause some boot-time error messages about not finding ndp (before /usr is mounted), but these can be ignored, as the backticked ndp line will be run EVERY time that rc.conf is sourced. This is just a work-around for 8.0 that happened to work for me at the time. If someone else has a better solution that fits properly within the confines of rc.conf, please speak up. While on the subject, I have been thinking about putting together a patchset to experiment with adding some improved logic surrounding using DHCPv6 vs DHPCPv4 vs SLAAC/RTSOL in the rc.conf scripts and adding M+0 flag support +rdnss (RFC 5006) support to the kernel and userland and devd. If I can ever get a working prototype, I will share to get some feedback. Good Luck. ---Dave Horn From owner-freebsd-net@FreeBSD.ORG Wed Jan 13 06:48:42 2010 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 1713F1065670 for ; Wed, 13 Jan 2010 06:48:42 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id B76988FC1D for ; Wed, 13 Jan 2010 06:48:41 +0000 (UTC) Received: (qmail 22354 invoked by uid 399); 13 Jan 2010 06:48:40 -0000 Received: from localhost (HELO ?192.168.0.110?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 13 Jan 2010 06:48:40 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Tue, 12 Jan 2010 22:48:43 -0800 (PST) From: Doug Barton To: Brett Lee In-Reply-To: <4B4CEB41.3000805@Sun.COM> Message-ID: References: <4B4CEB41.3000805@Sun.COM> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-message-flag: Outlook -- Not just for spreading viruses anymore! X-OpenPGP-Key-ID: 0xD5B2F0FB Organization: http://SupersetSolutions.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: How to enable IPv6 on a subset of interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 06:48:42 -0000 On Tue, 12 Jan 2010, Brett Lee wrote: > Hello, > > Using FreeBSD 8.0-RELEASE, and am trying variations in /etc/rc.conf in an > attempt to enable IPv6 on ONLY one of the systems two interfaces. > > Specifically, em0 should be enabled IPv4 DHCP, and bge0 should be enabled > IPv6 only. > > From the KAME link below, and the files /etc/network.subr and > /etc/defaults/rc.conf, am reading that "ipv6_network_interface" should work; > however the following still results in em0 obtaining IPv6 addresses: > > http://www.kame.net/~suz/freebsd-ipv6-config-guide.txt That link is prehistoric. While I haven't read it (past the date) I would not rely on it heavily. > ifconfig_em0="DHCP" > ipv6_enable="YES" > ipv6_network_interface="bge0" There is no such option in rc.conf. Spelling counts. :) > ipv6_network_interfaces="bge0" You want to include lo0 in this list. You haven't specified what IPv6 addresses you're seeing on em0 that you don't want to see. At minimum you will see the link local address (it starts with fe80::) but that is simply an artifact of having IPv6 in the kernel, and is not avoidable. It also isn't going to hurt anything. It would also be helpful if you could be more specific about what your goals are. In other words, why do you want IPv6 on only one interface? If we had more information we could help you better. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-net@FreeBSD.ORG Wed Jan 13 12:02:10 2010 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 AE3671065692 for ; Wed, 13 Jan 2010 12:02:10 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id 5EAAA8FC16 for ; Wed, 13 Jan 2010 12:02:09 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so198562qwe.7 for ; Wed, 13 Jan 2010 04:02:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=njbWo10T0X59kyPcz0XWAuGmIDZTVUrBddCAwFOAP2c=; b=JcnCqzJMr+2jlQDDma0rJxgB+ph/zR6ZEE/HnWzRNPzQxXfjKgU8rwrZxIqSDBh/m4 Fwo7Nsh5Wcyu4pU3apfQh86VBvaNsVEvuAjUR28/fBR/MV0OTfk3+znAzjOT5vGHTrvF oESHaQcNhlAT3xN8UqLd6qXYdo7adu7o1fSGc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=ECnW5cbIO9CBXeMc77/YN1J8KdrkMNYkHxij0XoT+eIG9iYm9VBxXZurykX8FEakXo 5ahiQPiV91ODEqE8oKt85R1+5TVn+KCtols2dtgtn2aa2Y/5PmJ3xSOG21lBxhmZgbMb 7CqFhLrO4OrIXrjzGYLnZ7C+kzg/Hw04DTC88= Received: by 10.224.50.137 with SMTP id z9mr2484189qaf.83.1263384126846; Wed, 13 Jan 2010 04:02:06 -0800 (PST) Received: from ?192.168.31.4? (ppp-21.103.dialinfree.com [209.172.21.103]) by mx.google.com with ESMTPS id 21sm1391923qyk.12.2010.01.13.04.01.59 (version=SSLv3 cipher=RC4-MD5); Wed, 13 Jan 2010 04:02:05 -0800 (PST) Sender: "J. Hellenthal" Message-ID: <4B4DB634.5040906@DataIX.net> Date: Wed, 13 Jan 2010 07:01:56 -0500 From: jhell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: David Horn References: <4B4CEB41.3000805@Sun.COM> <25ff90d61001121642l7ac1de26ma7033ca997d90183@mail.gmail.com> In-Reply-To: <25ff90d61001121642l7ac1de26ma7033ca997d90183@mail.gmail.com> X-Enigmail-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Brett Lee Subject: Re: How to enable IPv6 on a subset of interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 12:02:10 -0000 On 1/12/2010 7:42 PM, David Horn wrote: > On Tue, Jan 12, 2010 at 4:36 PM, Brett Lee wrote: >> Hello, >> >> Using FreeBSD 8.0-RELEASE, and am trying variations in /etc/rc.conf in an >> attempt to enable IPv6 on ONLY one of the systems two interfaces. >> >> Specifically, em0 should be enabled IPv4 DHCP, and bge0 should be enabled >> IPv6 only. >> >> From the KAME link below, and the files /etc/network.subr and >> /etc/defaults/rc.conf, am reading that "ipv6_network_interface" should work; >> however the following still results in em0 obtaining IPv6 addresses: >> >> http://www.kame.net/~suz/freebsd-ipv6-config-guide.txt >> >> ifconfig_em0="DHCP" >> ipv6_enable="YES" >> ipv6_network_interface="bge0" >> ipv6_network_interfaces="bge0" >> >> In another attempt (see link below), it looks like "ifconfig_em0" may >> support a "NOIPV6" param, but in practice it doesn't seem to work for me: >> >> http://lists.freebsd.org/pipermail/freebsd-rc/2007-May/001106.html >> >> ifconfig_em0="DHCP NOIPV6" >> ipv6_enable="YES" >> #ipv6_network_interface="bge0" >> #ipv6_network_interfaces="bge0" >> >> Am hopeful that someone might point out how I could enable this >> configuration. >> >> Thanks in advance! -Brett > > NOIPV6 is not a valid rc.conf configuration token at this time. > > I am assuming that you are using SLAAC for IPv6 prefix/address > distribution (via rtadvd/radvd), and not DHCPv6. > > ipv6_network_interfaces is the correct rc.conf(5) variable to use to > specifically control which interface gets configured using SLAAC via > rtsol(8), but will not stop other interfaces from getting the RA > (Router Advertisement) packet which starts IPv6 SLAAC (Stateless > Autoconfiguration). > > In -current/9.0 there are nice new ifconfig parameters (inet6 > ifdisabled -nud -accept_rtadv) and rc.conf variables that do just what > you are looking for, but they are not in 8.0 at this time. > > In 8.0 you can use the ndp(8) utility to set the -accept_rtadv (and/or > ifdisabled/nud,etc.) flags on a per-interface basis. The > "-accept_rtadv" flag will disable SLAAC for the specified interface, > but must be called before the interface gets the "RA" packet to be > effective. > > You can do an ugly *unsupported hack* in 8.0 to call ndp from within > rc.conf/rc.d startup scripts until the new code makes it into a > release: > > ipv6_enable="YES" > ipv6_network_interfaces="bge0" > ifconfig_em0="DHCP `ndp -i em0 ifdisabled -nud -accept_rtadv >/dev/null 2>&1`" > ifconfig_bge0="UP" > > This will cause some boot-time error messages about not finding ndp > (before /usr is mounted), but these can be ignored, as the backticked > ndp line will be run EVERY time that rc.conf is sourced. This is > just a work-around for 8.0 that happened to work for me at the time. > If someone else has a better solution that fits properly within the > confines of rc.conf, please speak up. > Not sure if 8.0 still has this cap but you could put you interface commands in /etc/start_if.em0 /etc/start_if.bge0. If this works out let me know I would be interested since it seems like a better idea rather than trying to set some weird options inside some rcvars. > While on the subject, I have been thinking about putting together a > patchset to experiment with adding some improved logic surrounding > using DHCPv6 vs DHPCPv4 vs SLAAC/RTSOL in the rc.conf scripts and > adding M+0 flag support +rdnss (RFC 5006) support to the kernel and > userland and devd. If I can ever get a working prototype, I will > share to get some feedback. > -- jhell From owner-freebsd-net@FreeBSD.ORG Wed Jan 13 16:23:05 2010 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 3C81B1065692 for ; Wed, 13 Jan 2010 16:23:05 +0000 (UTC) (envelope-from Brett.Lee@Sun.COM) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by mx1.freebsd.org (Postfix) with ESMTP id 1AD208FC1B for ; Wed, 13 Jan 2010 16:23:05 +0000 (UTC) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o0DGN4Us000683 for ; Wed, 13 Jan 2010 16:23:04 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KW7007001C8HU00@mail-amer.sun.com> for freebsd-net@freebsd.org; Wed, 13 Jan 2010 09:23:04 -0700 (MST) Received: from [192.168.1.11] ([unknown] [10.80.64.1]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KW700BOS1IDUO00@mail-amer.sun.com> for freebsd-net@freebsd.org; Wed, 13 Jan 2010 09:23:01 -0700 (MST) Date: Wed, 13 Jan 2010 09:22:58 -0700 From: Brett Lee In-reply-to: <25ff90d61001121642l7ac1de26ma7033ca997d90183@mail.gmail.com> Sender: Brett.Lee@Sun.COM To: freebsd-net@freebsd.org Message-id: <4B4DF362.9000007@Sun.COM> References: <4B4CEB41.3000805@Sun.COM> <25ff90d61001121642l7ac1de26ma7033ca997d90183@mail.gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Subject: Re: How to enable IPv6 on a subset of interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 16:23:05 -0000 David Horn wrote: > On Tue, Jan 12, 2010 at 4:36 PM, Brett Lee wrote: >> Hello, >> >> Using FreeBSD 8.0-RELEASE, and am trying variations in /etc/rc.conf in an >> attempt to enable IPv6 on ONLY one of the systems two interfaces. >> >> Specifically, em0 should be enabled IPv4 DHCP, and bge0 should be enabled >> IPv6 only. >> >> From the KAME link below, and the files /etc/network.subr and >> /etc/defaults/rc.conf, am reading that "ipv6_network_interface" should work; >> however the following still results in em0 obtaining IPv6 addresses: >> >> http://www.kame.net/~suz/freebsd-ipv6-config-guide.txt >> >> ifconfig_em0="DHCP" >> ipv6_enable="YES" >> ipv6_network_interface="bge0" >> ipv6_network_interfaces="bge0" >> >> In another attempt (see link below), it looks like "ifconfig_em0" may >> support a "NOIPV6" param, but in practice it doesn't seem to work for me: >> >> http://lists.freebsd.org/pipermail/freebsd-rc/2007-May/001106.html >> >> ifconfig_em0="DHCP NOIPV6" >> ipv6_enable="YES" >> #ipv6_network_interface="bge0" >> #ipv6_network_interfaces="bge0" >> >> Am hopeful that someone might point out how I could enable this >> configuration. >> >> Thanks in advance! -Brett > > NOIPV6 is not a valid rc.conf configuration token at this time. > > I am assuming that you are using SLAAC for IPv6 prefix/address > distribution (via rtadvd/radvd), and not DHCPv6. > > ipv6_network_interfaces is the correct rc.conf(5) variable to use to > specifically control which interface gets configured using SLAAC via > rtsol(8), but will not stop other interfaces from getting the RA > (Router Advertisement) packet which starts IPv6 SLAAC (Stateless > Autoconfiguration). > > In -current/9.0 there are nice new ifconfig parameters (inet6 > ifdisabled -nud -accept_rtadv) and rc.conf variables that do just what > you are looking for, but they are not in 8.0 at this time. > > In 8.0 you can use the ndp(8) utility to set the -accept_rtadv (and/or > ifdisabled/nud,etc.) flags on a per-interface basis. The > "-accept_rtadv" flag will disable SLAAC for the specified interface, > but must be called before the interface gets the "RA" packet to be > effective. > > You can do an ugly *unsupported hack* in 8.0 to call ndp from within > rc.conf/rc.d startup scripts until the new code makes it into a > release: > > ipv6_enable="YES" > ipv6_network_interfaces="bge0" > ifconfig_em0="DHCP `ndp -i em0 ifdisabled -nud -accept_rtadv >/dev/null 2>&1`" > ifconfig_bge0="UP" > > This will cause some boot-time error messages about not finding ndp > (before /usr is mounted), but these can be ignored, as the backticked > ndp line will be run EVERY time that rc.conf is sourced. This is > just a work-around for 8.0 that happened to work for me at the time. > If someone else has a better solution that fits properly within the > confines of rc.conf, please speak up. > > While on the subject, I have been thinking about putting together a > patchset to experiment with adding some improved logic surrounding > using DHCPv6 vs DHPCPv4 vs SLAAC/RTSOL in the rc.conf scripts and > adding M+0 flag support +rdnss (RFC 5006) support to the kernel and > userland and devd. If I can ever get a working prototype, I will > share to get some feedback. > > Good Luck. > > ---Dave Horn In trying this: ifconfig_em0="DHCP `ndp -i em0 (if?)disabled -nud -accept_rtadv >/dev/null 2>&1`" it seems like it will be "good enough" for our purposes. The em0 interface is not collecting the global SLAAC prefix and forming a global address; it is not learning about routers on that subnet; it is also not collecting reachability information about neighbors. The last one is probably the most important to us. The goal was to eliminate all global AND link local addressing/routing on em0, however, it was mentioned in one of the replies that this is not possible. This question arose from an effort is to use FreeBSD 8.0 to verify a test platform that consists of the myriad of Tahi IPv6 test suites, while still maintaining direct connectivity between this host and the v4/v6 LANs. With the solution above, I expect that this will suffice for our purposes. If not, will fall back to the serial console. Thanks everyone for your replies/suggestions! -Brett From owner-freebsd-net@FreeBSD.ORG Wed Jan 13 16:40:05 2010 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 B61B71065694 for ; Wed, 13 Jan 2010 16:40: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 8C4AF8FC13 for ; Wed, 13 Jan 2010 16:40:05 +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 o0DGe5Dm005923 for ; Wed, 13 Jan 2010 16:40:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0DGe5tL005922; Wed, 13 Jan 2010 16:40:05 GMT (envelope-from gnats) Date: Wed, 13 Jan 2010 16:40:05 GMT Message-Id: <201001131640.o0DGe5tL005922@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Jeff Blank Cc: Subject: Re: kern/142518: [em] [lagg] Problem on 8.0-STABLE with em and lagg X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jeff Blank List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 16:40:05 -0000 The following reply was made to PR kern/142518; it has been noted by GNATS. From: Jeff Blank To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/142518: [em] [lagg] Problem on 8.0-STABLE with em and lagg Date: Wed, 13 Jan 2010 11:37:16 -0500 On Mon, Jan 11, 2010 at 09:45:11AM +0000, linimon@FreeBSD.org wrote: > http://www.freebsd.org/cgi/query-pr.cgi?pr=142518 Please see also kern/141646. This may well be the same issue. Jeff From owner-freebsd-net@FreeBSD.ORG Wed Jan 13 17:50:37 2010 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 636AD106566B for ; Wed, 13 Jan 2010 17:50:37 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id 151E78FC18 for ; Wed, 13 Jan 2010 17:50:34 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id E165C48805; Wed, 13 Jan 2010 17:50:32 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1u-cVS5dnUU; Wed, 13 Jan 2010 17:50:30 +0000 (GMT) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 46574487C4; Wed, 13 Jan 2010 17:50:29 +0000 (GMT) Message-ID: <4B4E0777.2010109@tomjudge.com> Date: Wed, 13 Jan 2010 17:48:39 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: David Christensen References: <4AE72910.8090708@tomjudge.com> <4AE8CC59.7020004@tomjudge.com> <4AE9D10F.4040703@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A054DE883@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE9F576.4060101@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35A55@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA0B11.2050209@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35AB0@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA1183.7050306@tomjudge.com> <4AEB2571.7090006@tomjudge.com> <4AFAE428.5090907@quip.cz> <5D267A3F22FD854F8F48B3D2B52381933A20D4C55D@IRVEXCHCCR01.corp.ad.broadcom.com> <4AFAF542.8050004@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A20D4CA70@IRVEXCHCCR01.corp.ad.broadcom.com> <4AFC862B.6060805@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A20E0EFE1@IRVEXCHCCR01.corp.ad.broadcom.com> <5D267A3F22FD854F8F48B3D2B52381933A20E0F332@IRVEXCHCCR01.corp.ad.broadcom.com> <4B0C80FB.5040901@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A31581B0D@IRVEXCHCCR01.corp.ad.broadcom.com> In-Reply-To: <5D267A3F22FD854F8F48B3D2B52381933A31581B0D@IRVEXCHCCR01.corp.ad.broadcom.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jason Helfman , Gideon Naim , "rwilliams@borderware.com" , Miroslav Lachman <000.fbsd@quip.cz>, "net@freebsd.org" Subject: Re: bce(4) BCM5907 CTX write errors on 7.2 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: Wed, 13 Jan 2010 17:50:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Christensen wrote: >>> Does the attached patch make a difference for you? >> This patch seems to do the trick, on at least one of the >> R610's that we have. >> >> Just did cold boot, 5 warm boots, cold boot, 5 warm boots and >> have not had any issues. >> > > Thanks for testing. I want to pass the changes by a couple > other people before I go ahead with a commit. > > Dave > Hi Dave, I was just wondering when these changes will hit the tree, I have been running your patch in production for some time now and all seems well. Thanks Tom - -- TJU13-ARIN -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLTgd3AAoJEMSwVS7lr0Od0GkH/2sk3BGbMbOrpRtwj90FeZ5d y62yPU4cW3k+aWXOp+hj4zpfgyJBJFN8P0VtgBHiidPDhrpAGHL5vZNrK7XDoESL 1Kt4QvdQKXr60H8xKQT1zH1a6TL4r1o526/iJ7ksOOZv83VwvTZzYU6HP1MGPF7l OX0HjX2ifvJS/IFjt3eBsiboXN0L3EZ6XbJpeJL7KeHvQIPcDQMsxCppx+Stsm8B TwghGP2oihFzZ4D5yYyj2AJ6wNpJd2oyoZW1mxBmaRNj5U4Z37uwwjARY0efqZW7 6YmwMIMimsyzrXN6kbY9+pSG9cSm0zUba/7HcrkuVbER9ReVNh8wish4j4l4sm8= =Yzu5 -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Wed Jan 13 21:12:13 2010 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 72C0B1065679; Wed, 13 Jan 2010 21:12:13 +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 4A4388FC17; Wed, 13 Jan 2010 21:12:13 +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 o0DLCDBS044869; Wed, 13 Jan 2010 21:12:13 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0DLCDko044865; Wed, 13 Jan 2010 21:12:13 GMT (envelope-from gavin) Date: Wed, 13 Jan 2010 21:12:13 GMT Message-Id: <201001132112.o0DLCDko044865@freefall.freebsd.org> To: gavin@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/142774: Problem with outgoing connections on interface with multiple aliases 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, 13 Jan 2010 21:12:13 -0000 Synopsis: Problem with outgoing connections on interface with multiple aliases Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Wed Jan 13 21:09:15 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). To submitter: do you know if this configuration works on 7-STABLE? http://www.freebsd.org/cgi/query-pr.cgi?pr=142774 From owner-freebsd-net@FreeBSD.ORG Wed Jan 13 23:12:40 2010 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 9082A1065670; Wed, 13 Jan 2010 23:12:40 +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 678098FC08; Wed, 13 Jan 2010 23:12:40 +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 o0DNCetp049135; Wed, 13 Jan 2010 23:12:40 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0DNCepb049131; Wed, 13 Jan 2010 23:12:40 GMT (envelope-from linimon) Date: Wed, 13 Jan 2010 23:12:40 GMT Message-Id: <201001132312.o0DNCepb049131@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/142766: [ipw] [regression] ipw(4) with Intel PRO/wireless 2100 can't associate on FBSD 8 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, 13 Jan 2010 23:12:40 -0000 Old Synopsis: [regression] ipw(4) with Intel PRO/wireless 2100 can't associate on FBSD 8 New Synopsis: [ipw] [regression] ipw(4) with Intel PRO/wireless 2100 can't associate on FBSD 8 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jan 13 23:12:23 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=142766 From owner-freebsd-net@FreeBSD.ORG Thu Jan 14 01:40:05 2010 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 59DFA106566B for ; Thu, 14 Jan 2010 01:40: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 485148FC17 for ; Thu, 14 Jan 2010 01:40:05 +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 o0E1e5fI072465 for ; Thu, 14 Jan 2010 01:40:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0E1e5hr072464; Thu, 14 Jan 2010 01:40:05 GMT (envelope-from gnats) Date: Thu, 14 Jan 2010 01:40:05 GMT Message-Id: <201001140140.o0E1e5hr072464@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Floris Bos Cc: Subject: Re: kern/92090: [bge] bge: watchdog timeout -- resetting X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Floris Bos List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 01:40:05 -0000 The following reply was made to PR kern/92090; it has been noted by GNATS. From: Floris Bos To: bug-followup@freebsd.org Cc: Subject: Re: kern/92090: [bge] bge: watchdog timeout -- resetting Date: Thu, 14 Jan 2010 02:14:07 +0100 This might be a different problem, but I add it to this bug as I am getting the same error message. I have a brand new HP DL120 G6 server which has an on-board NIC that is based on the BCM5723 chipset. The NIC is not supported/recognized by FreeBSD 8, but the FreeBSD 9 (January snapshot) identifies it as: == bge0: mem 0xdf900000-0xdf90ffff irq 16 at device 0.0 on pci32 == After boot, the network works for about 5 seconds, barely enough time to get an IP by DHCP, and sent a ping or 2. Then network connectivity goes down, and after some time there is a "bge0: watchdog timeout -- resetting" message. Then network works again for 5 seconds, and goes down again. All the time, repeatedly. The system works fine under Ubuntu. So I assume the hardware is ok. Yours sincerley, Floris Bos From owner-freebsd-net@FreeBSD.ORG Thu Jan 14 02:55:42 2010 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 6A3251065676 for ; Thu, 14 Jan 2010 02:55:42 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id 1F2F98FC14 for ; Thu, 14 Jan 2010 02:55:41 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so453636qwe.7 for ; Wed, 13 Jan 2010 18:55:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=Xjyfyn4DMEXfJxK3ZJewKMBQWakEvx0YM1qDUe4CF5I=; b=MxCE+HzIEWYpoXI0ZIfivmYtP1WR508rVRQ+2FuNDyJTmVo466MJ+So3PXWqPDGp8u bxEgKMTGyirbfWfwyZcaaXbeQ3j9oHaoz00F5FtL9wUxaZenrHm8WBXqEDzMy50Q3B6r gF4Hnuc51OAw1Omx8FvKAo0owWCvoXkBqQ6r8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=kQAwfa4UxnQaoIXNUPOUp2t+7Ps/v2Db39YInK/hLOtQ1127LU7PPXJf6SQYw1rvZT SsTBrpqOHd7bsIdoJciSxNUKK+gkvNf4OsYUADlhhCZBhe6rfzcqTuKlAA2/ocUmZHOn +pFClfINNT4oOLWzvDS+caV55euOdHDzwMUDA= Received: by 10.224.109.141 with SMTP id j13mr116586qap.84.1263437734649; Wed, 13 Jan 2010 18:55:34 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 8sm529935qwj.43.2010.01.13.18.55.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 13 Jan 2010 18:55:33 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 13 Jan 2010 18:54:52 -0800 From: Pyun YongHyeon Date: Wed, 13 Jan 2010 18:54:52 -0800 To: Floris Bos Message-ID: <20100114025452.GU1228@michelle.cdnetworks.com> References: <201001140140.o0E1e5hr072464@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201001140140.o0E1e5hr072464@freefall.freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: kern/92090: [bge] bge: watchdog timeout -- resetting 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, 14 Jan 2010 02:55:42 -0000 On Thu, Jan 14, 2010 at 01:40:05AM +0000, Floris Bos wrote: > The following reply was made to PR kern/92090; it has been noted by GNATS. > > From: Floris Bos > To: bug-followup@freebsd.org > Cc: > Subject: Re: kern/92090: [bge] bge: watchdog timeout -- resetting > Date: Thu, 14 Jan 2010 02:14:07 +0100 > > This might be a different problem, but I add it to this bug as I am getting the same error message. > > > I have a brand new HP DL120 G6 server which has an on-board NIC that is based on the BCM5723 chipset. > The NIC is not supported/recognized by FreeBSD 8, but the FreeBSD 9 (January snapshot) identifies it as: > > == > bge0: mem 0xdf900000-0xdf90ffff irq 16 at device 0.0 on pci32 > == > > After boot, the network works for about 5 seconds, barely enough time to get an IP by DHCP, and sent a ping or 2. > Then network connectivity goes down, and after some time there is a "bge0: watchdog timeout -- resetting" message. > > Then network works again for 5 seconds, and goes down again. All the time, repeatedly. > > The system works fine under Ubuntu. So I assume the hardware is ok. > I'm not sure but it looks like you have a BCM5784 controller. What is the output of "devinfo -rv | grep phy"? From owner-freebsd-net@FreeBSD.ORG Thu Jan 14 04:05:16 2010 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 86D5C1065670 for ; Thu, 14 Jan 2010 04:05:16 +0000 (UTC) (envelope-from info@je-eigen-domein.nl) Received: from mx2.je-eigen-domein.nl (mx2.je-eigen-domein.nl [85.10.196.86]) by mx1.freebsd.org (Postfix) with ESMTP id 055DF8FC12 for ; Thu, 14 Jan 2010 04:05:15 +0000 (UTC) Received: from ubuntu.localnet (localhost [127.0.0.1]) by mx2.je-eigen-domein.nl (Postfix) with ESMTP id 94B5C7882DF; Thu, 14 Jan 2010 04:33:41 +0100 (CET) From: Floris Bos Organization: Maxnet To: pyunyh@gmail.com Date: Thu, 14 Jan 2010 04:33:19 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <201001140140.o0E1e5hr072464@freefall.freebsd.org> <20100114025452.GU1228@michelle.cdnetworks.com> In-Reply-To: <20100114025452.GU1228@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001140433.19229.info@je-eigen-domein.nl> Cc: freebsd-net@freebsd.org Subject: Re: kern/92090: [bge] bge: watchdog timeout -- resetting 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, 14 Jan 2010 04:05:16 -0000 Hi, On Thursday 14 January 2010 03:54:52 am Pyun YongHyeon wrote: > > == > > bge0: mem 0xdf900000-0xdf90ffff irq 16 at device 0.0 on pci32 > > == > > > > After boot, the network works for about 5 seconds, barely enough time to get an IP by DHCP, and sent a ping or 2. > > Then network connectivity goes down, and after some time there is a "bge0: watchdog timeout -- resetting" message. > > > > Then network works again for 5 seconds, and goes down again. All the time, repeatedly. > > > > The system works fine under Ubuntu. So I assume the hardware is ok. > > > > I'm not sure but it looks like you have a BCM5784 controller. What is > the output of "devinfo -rv | grep phy"? == ukphy0 pnpinfo oui=0x50ef model=0x3a rev=0x4 at phyno=1 ukphy1 pnpinfo oui=0x50ef model=0x3a rev=0x4 at phyno=1 == According to the specs in the HP manual it is supposed to be a BCM5723 ( http://www.dectrader.com/docs/set5/c01931407.pdf ) Yours sincerely, Floris Bos From owner-freebsd-net@FreeBSD.ORG Thu Jan 14 12:46:13 2010 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 4F6791065672 for ; Thu, 14 Jan 2010 12:46:13 +0000 (UTC) (envelope-from ga9@york.ac.uk) Received: from mail-gw1.york.ac.uk (mail-gw1.york.ac.uk [144.32.128.246]) by mx1.freebsd.org (Postfix) with ESMTP id E1B0D8FC1A for ; Thu, 14 Jan 2010 12:46:12 +0000 (UTC) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw1.york.ac.uk (8.13.6/8.13.6) with ESMTP id o0ECEdeq000086; Thu, 14 Jan 2010 12:14:39 GMT Received: from buffy-128.york.ac.uk ([144.32.128.160]) by mail-gw6.york.ac.uk with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1NVOb1-0000sI-KD; Thu, 14 Jan 2010 12:14:39 +0000 From: Gavin Atkinson To: Sam Wun In-Reply-To: <736c47cb1001111645v41e87672i201493ece1eb4ab0@mail.gmail.com> References: <736c47cb1001102049v71757b78oe954fd39f9d03118@mail.gmail.com> <736c47cb1001111645v41e87672i201493ece1eb4ab0@mail.gmail.com> Content-Type: text/plain; charset="ASCII" Date: Thu, 14 Jan 2010 12:14:39 +0000 Message-ID: <1263471279.8202.12.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Sender: ga9@york.ac.uk X-York-MailScanner: Found to be clean X-York-MailScanner-From: ga9@york.ac.uk Cc: freebsd-net@freebsd.org Subject: Re: freebsd for Sun Fire X4250 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, 14 Jan 2010 12:46:13 -0000 On Tue, 2010-01-12 at 11:45 +1100, Sam Wun wrote: > Hi Gavin, > > The reason I want to stick with i386 is because about few years ago > when I tried AMD release of FreeBSD, it didn't have the same level of > proficiency as i386 release of FreeBSD - packagThat was my impression > at that time. I hope it has changed in this years. > Is there any major installation difference between AMD (64) and i386 > release of FreeBSD (8.0)? These days, I suspect most developers are actually using amd64 as their primary platform. I would expect it to be supported as well, if not better than i386. I run amd64 on all of my machines, and have done for a couple of years now, and have not come across any issues that were unique to amd64. The main reason for recommending amd64, however, is because it is safe to assume the X4250 comes with at least 4GB of RAM. Using i386 would be a waste on this machine :) Gavin From owner-freebsd-net@FreeBSD.ORG Thu Jan 14 15:20:03 2010 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 5D451106566B for ; Thu, 14 Jan 2010 15: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 4B7BF8FC08 for ; Thu, 14 Jan 2010 15:20:03 +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 o0EFK3MF022258 for ; Thu, 14 Jan 2010 15: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 o0EFK2B1022257; Thu, 14 Jan 2010 15:20:03 GMT (envelope-from gnats) Date: Thu, 14 Jan 2010 15:20:03 GMT Message-Id: <201001141520.o0EFK2B1022257@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Bernhard Schmidt Cc: Subject: Re: kern/142018: [iwi] [patch] Possibly wrong interpretation of beacon-> number in if_iwi.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bernhard Schmidt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 15:20:03 -0000 The following reply was made to PR kern/142018; it has been noted by GNATS. From: Bernhard Schmidt To: bug-followup@freebsd.org, Andre.Albsmeier@siemens.com Cc: Subject: Re: kern/142018: [iwi] [patch] Possibly wrong interpretation of beacon->number in if_iwi.c Date: Thu, 14 Jan 2010 16:10:28 +0100 Hi, It might be simple endianess related issue, does this patch make any difference? Index: if_iwi.c =================================================================== --- sys/dev/iwi/if_iwi.c (revision 202285) +++ sys/dev/iwi/if_iwi.c (working copy) @@ -1499,9 +1499,9 @@ iwi_notification_intr(struct iwi_softc *sc, struct beacon = (struct iwi_notif_beacon_state *)(notif + 1); DPRINTFN(5, ("Beacon state (%u, %u)\n", - beacon->state, le32toh(beacon->number))); + le32toh(beacon->state), le32toh(beacon->number))); - if (beacon->state == IWI_BEACON_MISS) { + if (le32toh(beacon->state) == IWI_BEACON_MISS) { /* * The firmware notifies us of every beacon miss * so we need to track the count against the -- Bernhard From owner-freebsd-net@FreeBSD.ORG Thu Jan 14 16:03:36 2010 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 A8A461065672 for ; Thu, 14 Jan 2010 16:03:36 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from mailrelay1.rambler.ru (mailrelay1.rambler.ru [81.19.66.239]) by mx1.freebsd.org (Postfix) with ESMTP id 5525D8FC18 for ; Thu, 14 Jan 2010 16:03:36 +0000 (UTC) Received: from kas30pipe.localhost (localhost [127.0.0.1]) by mailrelay1.rambler.ru (Postfix) with ESMTP id 3AD05130C19; Thu, 14 Jan 2010 19:03:35 +0300 (MSK) Received: from localhost (sysoev.ru [81.19.68.137]) by mailrelay1.rambler.ru (Postfix) with ESMTP id 5A8B9130C61; Thu, 14 Jan 2010 19:03:33 +0300 (MSK) Date: Thu, 14 Jan 2010 19:03:33 +0300 From: Igor Sysoev To: Pyun YongHyeon Message-ID: <20100114160333.GC16657@rambler-co.ru> References: <20091204075440.GH14822@rambler-co.ru> <20091204173243.GC16491@michelle.cdnetworks.com> <20091204191114.GB76992@rambler-co.ru> <20091204195140.GH16491@michelle.cdnetworks.com> <20091204201303.GD76992@rambler-co.ru> <20091204202213.GI16491@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20091204202213.GI16491@michelle.cdnetworks.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Anti-Virus: Kaspersky Anti-Virus for MailServers 5.5.33/RELEASE, bases: 02092009 #2738642, status: clean X-SpamTest-Envelope-From: is@rambler-co.ru X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 9536 [Sen 02 2009] X-SpamTest-Info: {HEADERS: header Content-Type found without required header Content-Transfer-Encoding} X-SpamTest-Method: none X-SpamTest-Rate: 10 X-SpamTest-SPF: pass X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release Cc: freebsd-net@freebsd.org Subject: Re: hw.bge.forced_collapse 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, 14 Jan 2010 16:03:36 -0000 On Fri, Dec 04, 2009 at 12:22:13PM -0800, Pyun YongHyeon wrote: > On Fri, Dec 04, 2009 at 11:13:03PM +0300, Igor Sysoev wrote: > > On Fri, Dec 04, 2009 at 11:51:40AM -0800, Pyun YongHyeon wrote: > > > > > On Fri, Dec 04, 2009 at 10:11:14PM +0300, Igor Sysoev wrote: > > > > On Fri, Dec 04, 2009 at 09:32:43AM -0800, Pyun YongHyeon wrote: > > > > > > > > > On Fri, Dec 04, 2009 at 10:54:40AM +0300, Igor Sysoev wrote: > > > > > > I saw commit introducing hw.bge.forced_collapse loader tunable. > > > > > > Just intresting, why it can not be a sysctl ? > > > > > > > > > > I didn't think the sysctl variable would be frequently changed > > > > > in runtime except debugging driver so I took simple path. > > > > > > > > I do not think it's worth to reboot server just to look how various > > > > values affect on bandwidth and CPU usage, expecially in production. > > > > > > > > As I understand the change is trivial: > > > > > > > > - CTLFLAG_RD > > > > + CTLFLAG_RW > > > > > > > > since bge_forced_collapse is used atomically. > > > > > > > > > > I have no problem changing it to RW but that case I may have to > > > create actual sysctl node(e.g. dev.bge.0.forced_collapse) instead > > > of hw.bge.forced_collapse which may affect all bge(4) controllers > > > on system. Attached patch may be what you want. You can change the > > > value at any time. > > > > Thank you for the patch. Can it be installed on 8-STABLE ? > > > > bge(4) in HEAD has many fixes which were not MFCed to stable/8 so > I'm not sure that patch could be applied cleanly. But I guess you > can manually patch it. > I'll wait a couple of days for wider testing/review and commit the > patch. Sorry for the late response. We've tested bge.forced_collapse in December on HEAD and found that values >1 froze connections with big data amount, for example, "top -Ss1" output. Connection with small data amount such as short ssh commands worked OK. Now I've tested modern 7.2-STABLE and found that forced_collapse >1 freezes it too. -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Thu Jan 14 17:56:54 2010 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 06D76106566B for ; Thu, 14 Jan 2010 17:56:54 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f174.google.com (mail-qy0-f174.google.com [209.85.221.174]) by mx1.freebsd.org (Postfix) with ESMTP id 374D18FC14 for ; Thu, 14 Jan 2010 17:56:52 +0000 (UTC) Received: by qyk4 with SMTP id 4so11857624qyk.7 for ; Thu, 14 Jan 2010 09:56:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=OxvTBBP6c5lzSFmHU5XF/RrdHFYWU/Ey9Zm0jgDoPj0=; b=p0ZlG/KXKKIurwbo6PZFrhdraCGXigpaXlJX5yHPOb0k336Nyz6kxN7yWe/jGh57oc xxWm4Ire1n19QKFt+JKpzQtH9ZgIHpEyScSIwM9KbBZnNefn95y5WKh5C0AU5qL1c9+e CkrxjA3FbtGhoB2n3u9AAf0mQsp3VWofxgx6Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=hl+Qmblxws+c+t8jElS4sLhPS8YY45+SvOu8oUHNzCqOc1iL/yLMUB2dKy2knrWndq cTqPsKKbmlMs+mOqreBpOu2zHwnnnID3E9oRx1x0kTRbt1MAcvBSbkHPWAchSyG6/hdp haEOrdIWMrPBDMIU6Wk5VOVuwErzD1ZTXh2RU= Received: by 10.224.7.132 with SMTP id d4mr1049021qad.381.1263491809198; Thu, 14 Jan 2010 09:56:49 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 20sm799011qyk.1.2010.01.14.09.56.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 14 Jan 2010 09:56:46 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 14 Jan 2010 09:56:03 -0800 From: Pyun YongHyeon Date: Thu, 14 Jan 2010 09:56:03 -0800 To: Floris Bos Message-ID: <20100114175603.GW1228@michelle.cdnetworks.com> References: <201001140140.o0E1e5hr072464@freefall.freebsd.org> <20100114025452.GU1228@michelle.cdnetworks.com> <201001140433.19229.info@je-eigen-domein.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201001140433.19229.info@je-eigen-domein.nl> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: kern/92090: [bge] bge: watchdog timeout -- resetting 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, 14 Jan 2010 17:56:54 -0000 On Thu, Jan 14, 2010 at 04:33:19AM +0100, Floris Bos wrote: > Hi, > > On Thursday 14 January 2010 03:54:52 am Pyun YongHyeon wrote: > > > == > > > bge0: mem 0xdf900000-0xdf90ffff irq 16 at device 0.0 on pci32 > > > == > > > > > > After boot, the network works for about 5 seconds, barely enough time to get an IP by DHCP, and sent a ping or 2. > > > Then network connectivity goes down, and after some time there is a "bge0: watchdog timeout -- resetting" message. > > > > > > Then network works again for 5 seconds, and goes down again. All the time, repeatedly. > > > > > > The system works fine under Ubuntu. So I assume the hardware is ok. > > > > > > > I'm not sure but it looks like you have a BCM5784 controller. What is > > the output of "devinfo -rv | grep phy"? > > == > ukphy0 pnpinfo oui=0x50ef model=0x3a rev=0x4 at phyno=1 > ukphy1 pnpinfo oui=0x50ef model=0x3a rev=0x4 at phyno=1 > == Support for the PHY was added in r202269. Please try again after applying the change. Or you can download sys/dev/mii/miidevs and sys/dev/mii/brgphy.c from HEAD and rebuild kernel. > > According to the specs in the HP manual it is supposed to be a BCM5723 ( http://www.dectrader.com/docs/set5/c01931407.pdf ) > > > Yours sincerely, > > Floris Bos From owner-freebsd-net@FreeBSD.ORG Thu Jan 14 18:11:20 2010 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 5C1A8106568D for ; Thu, 14 Jan 2010 18:11:20 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id 0B6748FC27 for ; Thu, 14 Jan 2010 18:11:19 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so725373qwe.7 for ; Thu, 14 Jan 2010 10:11:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=DFpLeMLvBIW7kk8j9ILhC05v5KLMB6WihYuzj2S5hzA=; b=uMmGgNLs4YYym1dbvsRnJFDQBt1ScV7Y0MTP9sHV2srboU/zAYckv45cbF2tgBC9Jp H8dv/bJq2VuA7IHSAPj4y5BjQUAV1WGqrKE2Eh7bJEaQtPBVIjK7S2gYa3wC67+aHtyY FUmVSiMjCYFWslSCH3FRrRXNPiI5+PX6rSt2k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=JV7O8Ui1oLa5Fuj89XxHM8/5KKAysa1mEBk/KLNBPDehcrIcWR7HHp7PPW8HoPL6f1 Ik6cxlHXA9ZnP+lXAINW0wQndxcqkOhpB1MmIZL6JerlGc61QvXBkI6VHcPnurHBzN98 qHobbvItTbog6ZzBYzAvkm6pgK+HPKjwcQWD0= Received: by 10.224.32.149 with SMTP id c21mr1156520qad.33.1263492672238; Thu, 14 Jan 2010 10:11:12 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 8sm2408002qwj.3.2010.01.14.10.11.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 14 Jan 2010 10:11:11 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 14 Jan 2010 10:10:31 -0800 From: Pyun YongHyeon Date: Thu, 14 Jan 2010 10:10:31 -0800 To: Igor Sysoev Message-ID: <20100114181031.GX1228@michelle.cdnetworks.com> References: <20091204075440.GH14822@rambler-co.ru> <20091204173243.GC16491@michelle.cdnetworks.com> <20091204191114.GB76992@rambler-co.ru> <20091204195140.GH16491@michelle.cdnetworks.com> <20091204201303.GD76992@rambler-co.ru> <20091204202213.GI16491@michelle.cdnetworks.com> <20100114160333.GC16657@rambler-co.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="p8PhoBjPxaQXD0vg" Content-Disposition: inline In-Reply-To: <20100114160333.GC16657@rambler-co.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: hw.bge.forced_collapse 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, 14 Jan 2010 18:11:20 -0000 --p8PhoBjPxaQXD0vg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jan 14, 2010 at 07:03:33PM +0300, Igor Sysoev wrote: > On Fri, Dec 04, 2009 at 12:22:13PM -0800, Pyun YongHyeon wrote: > > > On Fri, Dec 04, 2009 at 11:13:03PM +0300, Igor Sysoev wrote: > > > On Fri, Dec 04, 2009 at 11:51:40AM -0800, Pyun YongHyeon wrote: > > > > > > > On Fri, Dec 04, 2009 at 10:11:14PM +0300, Igor Sysoev wrote: > > > > > On Fri, Dec 04, 2009 at 09:32:43AM -0800, Pyun YongHyeon wrote: > > > > > > > > > > > On Fri, Dec 04, 2009 at 10:54:40AM +0300, Igor Sysoev wrote: > > > > > > > I saw commit introducing hw.bge.forced_collapse loader tunable. > > > > > > > Just intresting, why it can not be a sysctl ? > > > > > > > > > > > > I didn't think the sysctl variable would be frequently changed > > > > > > in runtime except debugging driver so I took simple path. > > > > > > > > > > I do not think it's worth to reboot server just to look how various > > > > > values affect on bandwidth and CPU usage, expecially in production. > > > > > > > > > > As I understand the change is trivial: > > > > > > > > > > - CTLFLAG_RD > > > > > + CTLFLAG_RW > > > > > > > > > > since bge_forced_collapse is used atomically. > > > > > > > > > > > > > I have no problem changing it to RW but that case I may have to > > > > create actual sysctl node(e.g. dev.bge.0.forced_collapse) instead > > > > of hw.bge.forced_collapse which may affect all bge(4) controllers > > > > on system. Attached patch may be what you want. You can change the > > > > value at any time. > > > > > > Thank you for the patch. Can it be installed on 8-STABLE ? > > > > > > > bge(4) in HEAD has many fixes which were not MFCed to stable/8 so > > I'm not sure that patch could be applied cleanly. But I guess you > > can manually patch it. > > I'll wait a couple of days for wider testing/review and commit the > > patch. > > Sorry for the late response. We've tested bge.forced_collapse in December > on HEAD and found that values >1 froze connections with big data amount, > for example, "top -Ss1" output. Connection with small data amount such as > short ssh commands worked OK. Now I've tested modern 7.2-STABLE and found > that forced_collapse >1 freezes it too. > Thanks for reporting! It seems I've incorrectly dropped mbuf chains when collapsing fails. Would you try attached patch? --p8PhoBjPxaQXD0vg Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bge.collapse.patch5" Index: sys/dev/bge/if_bge.c =================================================================== --- sys/dev/bge/if_bge.c (revision 202268) +++ sys/dev/bge/if_bge.c (working copy) @@ -3940,11 +3940,8 @@ m = m_defrag(m, M_DONTWAIT); else m = m_collapse(m, M_DONTWAIT, sc->bge_forced_collapse); - if (m == NULL) { - m_freem(*m_head); - *m_head = NULL; - return (ENOBUFS); - } + if (m == NULL) + m = *m_head; *m_head = m; } --p8PhoBjPxaQXD0vg-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 14 18:30:53 2010 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 922921065676 for ; Thu, 14 Jan 2010 18:30:53 +0000 (UTC) (envelope-from w8hdkim@gmail.com) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id 6EB238FC14 for ; Thu, 14 Jan 2010 18:30:53 +0000 (UTC) Received: by pwi15 with SMTP id 15so4206845pwi.3 for ; Thu, 14 Jan 2010 10:30:47 -0800 (PST) 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:content-type; bh=J1IZ1W900cJx0c9wbfJDqlAR1rOdn8RTmVK1W5Qgm/U=; b=eHbQ3BzMeCkIcfocoWyBtf/mHKtTLOFWNsehpopVqwtcRcQSdkQuW9icFvwCHbzzX+ 5GghS1OFLLc+r67giTVkSkP0xchpmkAXUZ/wjA19QPU59WrW6pUbVTN7+raObvrv6dr8 tJiRpqYGbdlAav44JtqE5rd8c5KrTiCi2P6kI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ovSpNq1Ppl2f1+TvUmMuXA/4WvURcT3Jc00tGCwfVu3uRYJSAhlU57v0nXmlZ1R6u4 RD58WgHtd+ni7YyMTTB9Ve1w6k89wedKyRAG+7UYrKrtVIv+cRU8g7GJomszINqttSyq Yd7W4DOjjodIAOQj7yE48NBAUtdnYT4oL5nMc= MIME-Version: 1.0 Received: by 10.143.154.3 with SMTP id g3mr805910wfo.143.1263493847405; Thu, 14 Jan 2010 10:30:47 -0800 (PST) Date: Thu, 14 Jan 2010 13:30:47 -0500 Message-ID: <89dbfdc31001141030m21aff1d2m41e9ac6e16c68b22@mail.gmail.com> From: Kim Culhan To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: uath under FreeBSD 8.0-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 18:30:53 -0000 > On Thursday 24 December 2009 05:09:42 pm Weongyo Jeong wrote: > Yesterday I ordered `Netgear Wireless USB Adapter WG111T' which probably > is same one with you so I could reproduce your problem and debug it. Have you been successful so far ? -kim From owner-freebsd-net@FreeBSD.ORG Thu Jan 14 20:08:05 2010 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 D05311065679 for ; Thu, 14 Jan 2010 20:08:05 +0000 (UTC) (envelope-from info@je-eigen-domein.nl) Received: from mx2.je-eigen-domein.nl (mx2.je-eigen-domein.nl [85.10.196.86]) by mx1.freebsd.org (Postfix) with ESMTP id 9016C8FC20 for ; Thu, 14 Jan 2010 20:08:05 +0000 (UTC) Received: from ubuntu.localnet (localhost [127.0.0.1]) by mx2.je-eigen-domein.nl (Postfix) with ESMTP id EA2127881E7; Thu, 14 Jan 2010 21:08:17 +0100 (CET) From: Floris Bos Organization: Maxnet To: pyunyh@gmail.com Date: Thu, 14 Jan 2010 21:08:02 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <201001140140.o0E1e5hr072464@freefall.freebsd.org> <201001140433.19229.info@je-eigen-domein.nl> <20100114175603.GW1228@michelle.cdnetworks.com> In-Reply-To: <20100114175603.GW1228@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001142108.02941.info@je-eigen-domein.nl> Cc: freebsd-net@freebsd.org Subject: Re: kern/92090: [bge] bge: watchdog timeout -- resetting 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, 14 Jan 2010 20:08:05 -0000 On Thursday 14 January 2010 06:56:03 pm Pyun YongHyeon wrote: > On Thu, Jan 14, 2010 at 04:33:19AM +0100, Floris Bos wrote: > > Hi, > > > > On Thursday 14 January 2010 03:54:52 am Pyun YongHyeon wrote: > > > > == > > > > bge0: mem 0xdf900000-0xdf90ffff irq 16 at device 0.0 on pci32 > > > > == > > > > > > > > After boot, the network works for about 5 seconds, barely enough time to get an IP by DHCP, and sent a ping or 2. > > > > Then network connectivity goes down, and after some time there is a "bge0: watchdog timeout -- resetting" message. > > > > > > > > Then network works again for 5 seconds, and goes down again. All the time, repeatedly. > > > > > > > > The system works fine under Ubuntu. So I assume the hardware is ok. > > > > > > > > > > I'm not sure but it looks like you have a BCM5784 controller. What is > > > the output of "devinfo -rv | grep phy"? > > > > == > > ukphy0 pnpinfo oui=0x50ef model=0x3a rev=0x4 at phyno=1 > > ukphy1 pnpinfo oui=0x50ef model=0x3a rev=0x4 at phyno=1 > > == > > Support for the PHY was added in r202269. > Please try again after applying the change. Or you can download > sys/dev/mii/miidevs and sys/dev/mii/brgphy.c from HEAD and rebuild > kernel. Fetched the latest source using CVS on another computer, and transferred it to the system concerned by USB stick. Rebuild the kernel, but the problem is still there. Yours sincerely, Floris Bos From owner-freebsd-net@FreeBSD.ORG Thu Jan 14 20:12:38 2010 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 DCAA41065766 for ; Thu, 14 Jan 2010 20:12:36 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id 265A28FC0A for ; Thu, 14 Jan 2010 20:12:35 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so14013qwe.7 for ; Thu, 14 Jan 2010 12:12:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=lin+Ja/6M6RH+bfvIS2qSM8LyqRU063XfD7VleZctZI=; b=IHgCilJ887Su9x5ut0ao5cR68tVmJ+TR4Jh8DuMeEroV52jS5jGEVCrqlIZh12NdMe OAXvFK1lPtwsQbSSDtqjYiwXrBqAeR/OCKIinqDeuwpM8o6VqmM4EsbRGoxxskKyttCZ /N1qSoUI1UqCSpYGCCWDaO+fJD6SDfqCbytoM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=aIl16ypp66cZvPePRlVgQHSiAJG9pTm6J57jc4sbzvsslIBUefip5UrTk53RlwNGw5 vVAPuGF9HYzSHuAUX93bU72hCJUiRGoGFyeuZQQFLU3LaCtSHEO73f2VSNGidB6v50BJ 5oiNUOxjMS2YnaWsxpDOwKDNDloJ/bdLpgOwQ= Received: by 10.224.44.40 with SMTP id y40mr1345676qae.197.1263499946551; Thu, 14 Jan 2010 12:12:26 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 7sm2765145qwf.44.2010.01.14.12.12.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 14 Jan 2010 12:12:25 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 14 Jan 2010 12:11:44 -0800 From: Pyun YongHyeon Date: Thu, 14 Jan 2010 12:11:44 -0800 To: Floris Bos Message-ID: <20100114201144.GA1228@michelle.cdnetworks.com> References: <201001140140.o0E1e5hr072464@freefall.freebsd.org> <201001140433.19229.info@je-eigen-domein.nl> <20100114175603.GW1228@michelle.cdnetworks.com> <201001142108.02941.info@je-eigen-domein.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201001142108.02941.info@je-eigen-domein.nl> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: kern/92090: [bge] bge: watchdog timeout -- resetting 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, 14 Jan 2010 20:12:38 -0000 On Thu, Jan 14, 2010 at 09:08:02PM +0100, Floris Bos wrote: > On Thursday 14 January 2010 06:56:03 pm Pyun YongHyeon wrote: > > On Thu, Jan 14, 2010 at 04:33:19AM +0100, Floris Bos wrote: > > > Hi, > > > > > > On Thursday 14 January 2010 03:54:52 am Pyun YongHyeon wrote: > > > > > == > > > > > bge0: mem 0xdf900000-0xdf90ffff irq 16 at device 0.0 on pci32 > > > > > == > > > > > > > > > > After boot, the network works for about 5 seconds, barely enough time to get an IP by DHCP, and sent a ping or 2. > > > > > Then network connectivity goes down, and after some time there is a "bge0: watchdog timeout -- resetting" message. > > > > > > > > > > Then network works again for 5 seconds, and goes down again. All the time, repeatedly. > > > > > > > > > > The system works fine under Ubuntu. So I assume the hardware is ok. > > > > > > > > > > > > > I'm not sure but it looks like you have a BCM5784 controller. What is > > > > the output of "devinfo -rv | grep phy"? > > > > > > == > > > ukphy0 pnpinfo oui=0x50ef model=0x3a rev=0x4 at phyno=1 > > > ukphy1 pnpinfo oui=0x50ef model=0x3a rev=0x4 at phyno=1 > > > == > > > > Support for the PHY was added in r202269. > > Please try again after applying the change. Or you can download > > sys/dev/mii/miidevs and sys/dev/mii/brgphy.c from HEAD and rebuild > > kernel. > > Fetched the latest source using CVS on another computer, and transferred it to the system concerned by USB stick. > Rebuild the kernel, but the problem is still there. > Would you show me full dmesg output including "watchodg timeout" messages? From owner-freebsd-net@FreeBSD.ORG Thu Jan 14 20:49:00 2010 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 67AED106566B for ; Thu, 14 Jan 2010 20:49:00 +0000 (UTC) (envelope-from info@je-eigen-domein.nl) Received: from mx2.je-eigen-domein.nl (mx2.je-eigen-domein.nl [85.10.196.86]) by mx1.freebsd.org (Postfix) with ESMTP id AD9A68FC15 for ; Thu, 14 Jan 2010 20:48:59 +0000 (UTC) Received: from ubuntu.localnet (localhost [127.0.0.1]) by mx2.je-eigen-domein.nl (Postfix) with ESMTP id F0190788119; Thu, 14 Jan 2010 21:49:11 +0100 (CET) From: Floris Bos Organization: Maxnet To: pyunyh@gmail.com Date: Thu, 14 Jan 2010 21:48:56 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <201001140140.o0E1e5hr072464@freefall.freebsd.org> <201001142108.02941.info@je-eigen-domein.nl> <20100114201144.GA1228@michelle.cdnetworks.com> In-Reply-To: <20100114201144.GA1228@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001142148.56444.info@je-eigen-domein.nl> Cc: freebsd-net@freebsd.org Subject: Re: kern/92090: [bge] bge: watchdog timeout -- resetting 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, 14 Jan 2010 20:49:00 -0000 On Thursday 14 January 2010 09:11:44 pm Pyun YongHyeon wrote: > On Thu, Jan 14, 2010 at 09:08:02PM +0100, Floris Bos wrote: > > On Thursday 14 January 2010 06:56:03 pm Pyun YongHyeon wrote: > > > On Thu, Jan 14, 2010 at 04:33:19AM +0100, Floris Bos wrote: > > > > Hi, > > > > > > > > On Thursday 14 January 2010 03:54:52 am Pyun YongHyeon wrote: > > > > > > == > > > > > > bge0: mem 0xdf900000-0xdf90ffff irq 16 at device 0.0 on pci32 > > > > > > == > > > > > > > > > > > > After boot, the network works for about 5 seconds, barely enough time to get an IP by DHCP, and sent a ping or 2. > > > > > > Then network connectivity goes down, and after some time there is a "bge0: watchdog timeout -- resetting" message. > > > > > > > > > > > > Then network works again for 5 seconds, and goes down again. All the time, repeatedly. > > > > > > > > > > > > The system works fine under Ubuntu. So I assume the hardware is ok. > > > > > > > > > > > > > > > > I'm not sure but it looks like you have a BCM5784 controller. What is > > > > > the output of "devinfo -rv | grep phy"? > > > > > > > > == > > > > ukphy0 pnpinfo oui=0x50ef model=0x3a rev=0x4 at phyno=1 > > > > ukphy1 pnpinfo oui=0x50ef model=0x3a rev=0x4 at phyno=1 > > > > == > > > > > > Support for the PHY was added in r202269. > > > Please try again after applying the change. Or you can download > > > sys/dev/mii/miidevs and sys/dev/mii/brgphy.c from HEAD and rebuild > > > kernel. > > > > Fetched the latest source using CVS on another computer, and transferred it to the system concerned by USB stick. > > Rebuild the kernel, but the problem is still there. > > > Would you show me full dmesg output including "watchodg timeout" > messages? === Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #0: Thu Jan 14 20:12:47 CET 2010 root@db3.xxxxxxx.xx:/usr/obj/usr/src/sys/GENERIC amd64 WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU X3430 @ 2.40GHz (2394.00-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106e5 Stepping = 5 Features=0xbfebfbff Features2=0x98e3fd AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant real memory = 17179869184 (16384 MB) avail memory = 16533999616 (15768 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 3.0 on pci0 pci1: on pcib1 pci0: at device 8.0 (no driver attached) pci0: at device 8.1 (no driver attached) pci0: at device 8.2 (no driver attached) pci0: at device 8.3 (no driver attached) pci0: at device 16.0 (no driver attached) pci0: at device 16.1 (no driver attached) ehci0: mem 0xdfd02000-0xdfd023ff irq 16 at device 26.0 on pci0 ehci0: [ITHREAD] usbus0: EHCI version 1.0 usbus0: on ehci0 pcib2: irq 17 at device 28.0 on pci0 pci16: on pcib2 pcib3: irq 17 at device 28.4 on pci0 pci32: on pcib3 bge0: mem 0xdf900000-0xdf90ffff irq 16 at device 0.0 on pci32 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: f4:ce:46:0f:2a:2c bge0: [FILTER] pcib4: irq 16 at device 28.5 on pci0 pci34: on pcib4 bge1: mem 0xdfa00000-0xdfa0ffff irq 17 at device 0.0 on pci34 miibus1: on bge1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge1: Ethernet address: f4:ce:46:0f:2a:2d bge1: [FILTER] pcib5: irq 18 at device 28.6 on pci0 pci36: on pcib5 vgapci0: mem 0xde000000-0xdeffffff,0xdf800000-0xdf803fff,0xdf000000-0xdf7fffff irq 18 at device 0.0 on pci36 pcib6: irq 19 at device 28.7 on pci0 pci38: on pcib6 ehci1: mem 0xdfd02400-0xdfd027ff irq 23 at device 29.0 on pci0 ehci1: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci1 pcib7: at device 30.0 on pci0 pci48: on pcib7 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1830-0x1837,0x1824-0x1827,0x1828-0x182f,0x1820-0x1823,0x1800-0x181f mem 0xdfd01000-0xdfd017ff irq 18 at device 31.2 on pci0 atapci0: [ITHREAD] atapci0: AHCI v1.30 controller with 6 3Gbps ports, PM supported ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x71 on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 p4tcc3: on cpu3 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc8fff,0xdc000-0xdffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd: unable to set the command byte. atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to set the command byte. ppc0: cannot reserve I/O port range ZFS filesystem version 3 ZFS storage pool version 14 Timecounters tick every 1.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ad4: 152627MB at ata2-master UDMA100 SATA 3Gb/s ad6: 152627MB at ata3-master UDMA100 SATA 3Gb/s ad8: 152627MB at ata4-master UDMA100 SATA 3Gb/s ad10: 152627MB at ata5-master UDMA100 SATA 3Gb/s SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! WARNING: WITNESS option enabled, expect reduced performance. ugen1.1: at usbus1ugen0.1: at usbus0 uhub0: on usbus1 uhub1: on usbus0 Root mount waiting for: usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus1 usbus0 ugen1.2: at usbus1 uhub2: on usbus1 ugen0.2: at usbus0 uhub3: on usbus0 Root mount waiting for: usbus1 usbus0 uhub3: 6 ports with 6 removable, self powered uhub2: 8 ports with 8 removable, self powered Root mount waiting for: usbus1 usbus0 ugen0.3: at usbus0 ums0: on usbus0 ums0: 8 buttons and [XYZ] coordinates ID=0 ugen1.3: at usbus1 ukbd0: on usbus1 kbd2 at ukbd0 ums1: on usbus1 ums1: 8 buttons and [XYZ] coordinates ID=0 ugen0.4: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x0000 Root mount waiting for: usbus0 umass0:0:0:-1: Attached to scbus0 Trying to mount root from zfs:zroot da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3839MB (7862911 512 byte sectors: 255H 63S/T 489C) GEOM: da0: partition 1 does not end on a track boundary. lock order reversal: 1st 0xffffff000a372bd8 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1058 2nd 0xffffff000a5bc9f8 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2091 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xd10 vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vget() at vget+0x7b devfs_allocv() at devfs_allocv+0x100 devfs_root() at devfs_root+0x48 vfs_donmount() at vfs_donmount+0xfb2 nmount() at nmount+0x63 syscall() at syscall+0x1ae Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (378, FreeBSD ELF64, nmount), rip = 0x8007afeac, rsp = 0x7fffffffdd28, rbp = 0x800a06048 --- bge0: link state changed to UP bge0: link state changed to DOWN bge0: watchdog timeout -- resetting bge0: link state changed to UP bge0: link state changed to DOWN bge0: watchdog timeout -- resetting bge0: link state changed to UP bge0: watchdog timeout -- resetting bge0: link state changed to DOWN bge0: link state changed to UP === Seconds after the link goes up the connectivity is gone, but it takes minutes before it actually shows up as "link state changed to DOWN" in dmesg. According to the log file of the switch the server is connected to, the link goes up and down every 3 seconds or so. == Log Index Message Text Severity Log Time Component Description 1700 <14> Jan 01 09:27:45 197 192.168.2.10-1 NIM[-2137017720]: nim_events.c(619) 1701 %% Interface 9 is Link Up Info Jan 01 09:27:45 NIM Interface 9 is Link Up 1701 <14> Jan 01 09:27:48 197 192.168.2.10-1 NIM[-2137017720]: nim_events.c(665) 1702 %% Interface 9 is Link Down Info Jan 01 09:27:48 NIM Interface 9 is Link Down 1702 <14> Jan 01 09:27:51 197 192.168.2.10-1 NIM[-2137017720]: nim_events.c(619) 1703 %% Interface 9 is Link Up Info Jan 01 09:27:51 NIM Interface 9 is Link Up 1703 <14> Jan 01 09:27:54 197 192.168.2.10-1 NIM[-2137017720]: nim_events.c(665) 1704 %% Interface 9 is Link Down Info Jan 01 09:27:54 NIM Interface 9 is Link Down 1704 <14> Jan 01 09:27:57 197 192.168.2.10-1 NIM[-2137017720]: nim_events.c(619) 1705 %% Interface 9 is Link Up Info Jan 01 09:27:57 NIM Interface 9 is Link Up 1705 <14> Jan 01 09:28:00 197 192.168.2.10-1 NIM[-2137017720]: nim_events.c(665) 1706 %% Interface 9 is Link Down Info Jan 01 09:28:00 NIM Interface 9 is Link Down 1706 <14> Jan 01 09:28:03 197 192.168.2.10-1 NIM[-2137017720]: nim_events.c(619) 1707 %% Interface 9 is Link Up Info Jan 01 09:28:03 NIM Interface 9 is Link Up 1707 <14> Jan 01 09:28:06 197 192.168.2.10-1 NIM[-2137017720]: nim_events.c(665) 1708 %% Interface 9 is Link Down Info Jan 01 09:28:06 NIM Interface 9 is Link Down 1708 <14> Jan 01 09:28:09 197 192.168.2.10-1 NIM[-2137017720]: nim_events.c(619) 1709 %% Interface 9 is Link Up Info Jan 01 09:28:09 NIM Interface 9 is Link Up 1709 <14> Jan 01 09:28:12 197 192.168.2.10-1 NIM[-2137017720]: nim_events.c(665) 1710 %% Interface 9 is Link Down Info Jan 01 09:28:12 NIM Interface 9 is Link Down 1710 <14> Jan 01 09:28:15 197 192.168.2.10-1 NIM[-2137017720]: nim_events.c(619) 1711 %% Interface 9 is Link Up Info Jan 01 09:28:15 NIM Interface 9 is Link Up 1711 <14> Jan 01 09:28:17 197 192.168.2.10-1 NIM[-2137017720]: nim_events.c(665) 1712 %% Interface 9 is Link Down Info Jan 01 09:28:17 NIM Interface 9 is Link Down 1712 <14> Jan 01 09:28:20 197 192.168.2.10-1 NIM[-2137017720]: nim_events.c(619) 1713 %% Interface 9 is Link Up Info Jan 01 09:28:20 NIM Interface 9 is Link Up 1713 <14> Jan 01 09:28:24 197 192.168.2.10-1 NIM[-2137017720]: nim_events.c(665) 1714 %% Interface 9 is Link Down Info Jan 01 09:28:24 NIM Interface 9 is Link Down 1714 <14> Jan 01 09:28:26 197 192.168.2.10-1 NIM[-2137017720]: nim_events.c(619) 1715 %% Interface 9 is Link Up Info Jan 01 09:28:26 NIM Interface 9 is Link Up 1715 <14> Jan 01 09:28:30 197 192.168.2.10-1 NIM[-2137017720]: nim_events.c(665) 1716 %% Interface 9 is Link Down Info Jan 01 09:28:30 NIM Interface 9 is Link Down 1716 <14> Jan 01 09:28:32 197 192.168.2.10-1 NIM[-2137017720]: nim_events.c(619) 1717 %% Interface 9 is Link Up Info Jan 01 09:28:32 NIM Interface 9 is Link Up 1717 <14> Jan 01 09:28:36 197 192.168.2.10-1 NIM[-2137017720]: nim_events.c(665) 1718 %% Interface 9 is Link Down Info Jan 01 09:28:36 NIM Interface 9 is Link Down 1718 <14> Jan 01 09:28:39 197 192.168.2.10-1 NIM[-2137017720]: nim_events.c(619) 1719 %% Interface 9 is Link Up Info Jan 01 09:28:39 NIM Interface 9 is Link Up 1719 <14> Jan 01 09:28:42 197 192.168.2.10-1 NIM[-2137017720]: nim_events.c(665) 1720 %% Interface 9 is Link Down Info Jan 01 09:28:42 NIM Interface 9 is Link Down 1720 <14> Jan 01 09:28:45 197 192.168.2.10-1 NIM[-2137017720]: nim_events.c(619) 1721 %% Interface 9 is Link Up Info Jan 01 09:28:45 NIM Interface 9 is Link Up 1721 <14> Jan 01 09:28:48 197 192.168.2.10-1 NIM[-2137017720]: nim_events.c(665) 1722 %% Interface 9 is Link Down Info Jan 01 09:28:48 NIM Interface 9 is Link Down 1722 <14> Jan 01 09:28:51 197 192.168.2.10-1 NIM[-2137017720]: nim_events.c(619) 1723 %% Interface 9 is Link Up Info Jan 01 09:28:51 NIM Interface 9 is Link Up 1723 <14> Jan 01 09:28:54 197 192.168.2.10-1 NIM[-2137017720]: nim_events.c(665) 1724 %% Interface 9 is Link Down Info Jan 01 09:28:54 NIM Interface 9 is Link Down == Yours sincerly, Floris Bos From owner-freebsd-net@FreeBSD.ORG Thu Jan 14 22:10:30 2010 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 AE807106566C for ; Thu, 14 Jan 2010 22:10:30 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 74DB58FC17 for ; Thu, 14 Jan 2010 22:10:30 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1NVXtd-0001Bk-Nb for freebsd-net@freebsd.org; Thu, 14 Jan 2010 14:10:29 -0800 Message-ID: <27168938.post@talk.nabble.com> Date: Thu, 14 Jan 2010 14:10:29 -0800 (PST) From: "M. Jones" To: freebsd-net@freebsd.org In-Reply-To: <4B4E0777.2010109@tomjudge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: mjonesfreebsd@mailinator.com References: <4AE72910.8090708@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B49180@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE76FF1.9010401@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B491AE@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE8CC59.7020004@tomjudge.com> <4AE9D10F.4040703@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A054DE883@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE9F576.4060101@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35A55@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA0B11.2050209@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35AB0@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA1183.7050306@tomjudge.com> <4AEB2571.7090006@tomjudge.com> <4AFAE428.5090907@quip.cz> <5D267A3F22FD854F8F48B3D2B52381933A20D4C55D@IRVEXCHCCR01.corp.ad.broadcom.com> <4AFAF542.8050004@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A20D4CA70@IRVEXCHCCR01.corp.ad.broadcom.com> <4AFC862B.6060805@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A20E0EFE1@IRVEXCHCCR01.corp.ad.broadcom.com> <5D267A3F22FD854F8F48B3D2B52381933A20E0F332@IRVEXCHCCR01.corp.ad.broadcom.com> <4B0C80FB.5040901@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A31581B0D@IRVEXCHCCR01.corp.ad.broadcom.com> <4B4E0777.2010109@tomjudge.com> Subject: Re: bce(4) BCM5907 CTX write errors on 7.2 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: Thu, 14 Jan 2010 22:10:30 -0000 Hello, We've been using this patch in production on four servers for a number of weeks, and it has worked 100%. Systems are all Dell R610, and run 7.2-RELEASE as well as 8.0-RELEASE. Regards, M. Jones Tom Judge wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > David Christensen wrote: >>>> Does the attached patch make a difference for you? >>> This patch seems to do the trick, on at least one of the >>> R610's that we have. >>> >>> Just did cold boot, 5 warm boots, cold boot, 5 warm boots and >>> have not had any issues. >>> >> >> Thanks for testing. I want to pass the changes by a couple >> other people before I go ahead with a commit. >> >> Dave >> > > Hi Dave, > > I was just wondering when these changes will hit the tree, I have been > running your patch in production for some time now and all seems well. > > > Thanks > > Tom > > - -- > TJU13-ARIN > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.13 (FreeBSD) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJLTgd3AAoJEMSwVS7lr0Od0GkH/2sk3BGbMbOrpRtwj90FeZ5d > y62yPU4cW3k+aWXOp+hj4zpfgyJBJFN8P0VtgBHiidPDhrpAGHL5vZNrK7XDoESL > 1Kt4QvdQKXr60H8xKQT1zH1a6TL4r1o526/iJ7ksOOZv83VwvTZzYU6HP1MGPF7l > OX0HjX2ifvJS/IFjt3eBsiboXN0L3EZ6XbJpeJL7KeHvQIPcDQMsxCppx+Stsm8B > TwghGP2oihFzZ4D5yYyj2AJ6wNpJd2oyoZW1mxBmaRNj5U4Z37uwwjARY0efqZW7 > 6YmwMIMimsyzrXN6kbY9+pSG9cSm0zUba/7HcrkuVbER9ReVNh8wish4j4l4sm8= > =Yzu5 > -----END PGP SIGNATURE----- > _______________________________________________ > 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" > > -- View this message in context: http://old.nabble.com/bce%284%29-BCM5907-CTX-write-errors-on-7.2-driver-tp26081795p27168938.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Thu Jan 14 22:33:31 2010 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 F0105106566B for ; Thu, 14 Jan 2010 22:33:31 +0000 (UTC) (envelope-from callumgibson@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id 6FA658FC18 for ; Thu, 14 Jan 2010 22:33:31 +0000 (UTC) Received: from omma.gibson.athome (c122-106-69-195.rivrw1.nsw.optusnet.com.au [122.106.69.195]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with SMTP id o0EMXToE001931 for ; Fri, 15 Jan 2010 09:33:29 +1100 Received: (qmail 75431 invoked by uid 107); 15 Jan 2010 09:33:28 +1100 Date: 15 Jan 2010 09:33:28 +1100 Resent-From: callumgibson@optusnet.com.au Resent-Date: Fri, 15 Jan 2010 09:33:28 +1100 Resent-Message-ID: <20100114223328.GA71964@omma.gibson.athome> Resent-To: freebsd-net@freebsd.org Date: Fri, 15 Jan 2010 09:32:41 +1100 From: Callum Gibson To: freebsd-net@freebsd.org Message-ID: <20100114223241.GA67640@omma.gibson.athome> References: <20100112032554.GA40871@omma.gibson.athome> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100112032554.GA40871@omma.gibson.athome> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: lagg doesn't fail back to master 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, 14 Jan 2010 22:33:32 -0000 On 12Jan10 14:25, Callum Gibson wrote: }I have the following in my rc.conf: } }wlans_bwi0="wlan0" }ifconfig_bwi0="ether XXX" }ifconfig_wlan0="WPA mode 11g" }cloned_interfaces="lagg0" }ifconfig_lagg0="SYNCDHCP laggproto failover laggport bge0 laggport wlan0" } }This seems to work fine at boot. However, once I plug wired back in, }lagg doesn't switch back to the master. Here is what ifconfig is showing: Thanks for the replies. For the list, the solution was to add the following to rc.conf: ifconfig_bge0="up" C -- Callum Gibson @ home http://members.optusnet.com.au/callumgibson/ From owner-freebsd-net@FreeBSD.ORG Thu Jan 14 22:46:41 2010 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 6AD0E106566C for ; Thu, 14 Jan 2010 22:46:41 +0000 (UTC) (envelope-from erik@malcolm.berkeley.edu) Received: from malcolm.berkeley.edu (malcolm.Berkeley.EDU [IPv6:2607:f140:ffff:ffff::239]) by mx1.freebsd.org (Postfix) with ESMTP id 4C0228FC0C for ; Thu, 14 Jan 2010 22:46:41 +0000 (UTC) Received: from malcolm.berkeley.edu (localhost [127.0.0.1]) by malcolm.berkeley.edu (8.14.3/8.13.8m1) with ESMTP id o0EMkZ3r027314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 14 Jan 2010 14:46:36 -0800 (PST) (envelope-from erik@malcolm.berkeley.edu) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at malcolm.berkeley.edu Received: (from erik@localhost) by malcolm.berkeley.edu (8.14.3/8.13.3/Submit) id o0EMkZHr027313 for freebsd-net@freebsd.org; Thu, 14 Jan 2010 14:46:35 -0800 (PST) (envelope-from erik) Date: Thu, 14 Jan 2010 14:46:35 -0800 From: Erik Klavon To: freebsd-net@freebsd.org Message-ID: <20100114224635.GA27139@malcolm.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (malcolm.berkeley.edu [127.0.0.1]); Thu, 14 Jan 2010 14:46:36 -0800 (PST) Subject: netgraph mkpeer and connect failures with ng_ipfw and ng_nat 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, 14 Jan 2010 22:46:41 -0000 Hi I have several dual processor, single core amd64 machines running 8.0p1. These machines use netgraph to implement one to one NAT with one ng_nat(4) node for each network client behind them. ipfw(8) rules direct traffic to netgraph nodes as needed based on table entries using an ng_ipfw(4) node. As clients join and leave the network, scripts dynamically create and delete NAT sessions by making calls to ipfw(8), ngctl(8) and arp(8) to create and delete ng_nat(4) nodes, ipfw(8) table and published ARP entries. This scheme has worked well so far in all places we're using it except one. In the problematic case, immediately following boot up, creation and deletion of sessions work consistently. After a couple of hours, long enough for roughly 100 session creations and deletions, creation and deletion of sessions will occasionally fail during calls to ngctl(8). In all other cases, creation and deletion of sessions work consistently. The rate of session change appears to be greater in the problematic case, though the total number of active sessions when session creation and deletion start to fail is below the total number of sessions we see in non problematic cases. I have swapped out the machine in the problematic case with another machine with an identical configuration. This did not result in a change in behavior. Here are the calls to ngctl(8) we use to create a one to one NAT session, with the first two octets in the globally routable IPv4 addresses replaced with an "x". ngctl mkpeer ipfw: nat 202182094 out ngctl name ipfw:202182094 WirelessNAT2182094 ngctl connect ipfw: WirelessNAT2182094: 102182094 in ngctl msg WirelessNAT2182094: setaliasaddr x.x.182.94 ngctl msg WirelessNAT2182094: redirectaddr \ '{'"local_addr=10.10.115.242" "alias_addr=x.x.182.94" \ 'description="Static NAT"' '}' For the identifiers above, we represent the globally routable IPv4 address by an integer such as 2182094. The first digit of this integer represents the first two octets in the address (all addresses used have the same first two octets). The remaining digits are the third and forth octets with padded leading zeros as needed. We generate the hook names by prepending a two digit int representing the direction (20 out, 10 in) to the integer representing the globally routable IPv4 address. This guarantees unique identifiers for all hooks and ng_nat(4) node names. We use multiple checks in the script that calls ngctl(8) to ensure that each globally routable address is used in exactly one session. We use a lock around the above calls prevent two session creation attempts from interleaving their ngctl(8) calls. Here is the call to ngctl(8) we use to delete a one to one NAT session. The lock around this call is the same used for creating a session. ngctl shutdown ipfw:202182094 The first error leading to a session creation or deletion failure after booting I've observed is in the mkpeer call. Here is an example from yesterday, after booting the machine at roughly 0500. Jan 13 08:44:42 nac[11721]: ngctl: send msg: File exists Jan 13 08:44:42 nac[11722]: warning: Unsuccessful execution: /usr/sbin/ngctl mkpeer ipfw: nat 202182094 out This mkpeer call is the first time since boot that the globally routable IP address x.x.182.94 was used and the first attempt to create a hook named 202182094. Output from vmstat(8) -z captured every minute shows no incrementing of the allocation failure counters from well before 0844 to 0848. Reducing the number of netgraph threads (from 2 to 1) via the sysctl net.graph.threads has not had an effect on this problem. I can not think of any obvious reasons why this mkpeer call might have failed. 102 mkpeer calls prior to it did not. When a mkpeer call succeeds, the subsequent connect call in the above session creation sequence will fail, also with a "File exists" error. The next failure after the above example from yesterday is an example of this problem. Jan 13 08:51:45 nac[51209]: ngctl: send msg: File exists Jan 13 08:51:45 nac[51212]: warning: Unsuccessful execution: /usr/sbin/ngctl connect ipfw: WirelessNAT2175205: 102175205 in Also in this case, this is the first time since boot that the globally routable IP address x.x.175.205 was used and the first attempt to create a hook named 102175205. Output from vmstat(8) -z captured every minute shows no incrementing of the allocation failure counters from 0849 to 0900. There is an increment of the allocation failure counter for the 128 Bucket in vmstat(8) -z between 0848 and 0849; I assume that this is too far away in time from the two above events to be related. Also, the "File exists" error results from a check I don't think is related to memory allocation (see below). This morning prior to a reboot I modified the ngctl(8) calls to include the -d flag and obtained the following additional information. Jan 14 08:35:08 nac[3234]: ngctl: sendto(ipfw:): File exists Jan 14 08:35:08 nac[3234]: ngctl: send msg: File exists Jan 14 08:35:08 nac[3235]: warning: Unsuccessful execution: /usr/sbin/ngctl -d mkpeer ipfw: nat 202183148 out Jan 14 08:47:50 nac[94270]: ngctl: sendto(ipfw:): File exists Jan 14 08:47:50 nac[94270]: ngctl: send msg: File exists Jan 14 08:47:50 nac[94271]: warning: Unsuccessful execution: /usr/sbin/ngctl -d connect ipfw: WirelessNAT2175111: 102175111 in This points to ng_ipfw(4) as the source of these errors. I took a very quick look at the code to come up with the following interpretations; please let me know if you see any mistakes in the following. It looks to me like the error string "File exists" is displayed by ngctl(8) when the EEXIST constant is returned from ng_ipfw(4) when processing the command issued via ngctl(8). There is one place in ng_ipfw(4) where EEXIST is returned. This section of code appears to be used only when the single ipfw(8) node is first created, so I don't think it should be the source of the problem in this case. This leaves the parts of ng_base used to handle generic operations. EEXIST is returned by ng_base.c in the following functions. ng_newtype (called when a new netgraph type is installed) ng_add_hook (add an unconnected hook to a node) ng_con_nodes (connect this node with another node) ng_con_part2 (make the connection in the opposite direction of ng_con_nodes) ng_newtype probably isn't the source of the problem in this case, since we're not working with a new type. The other three functions are possible candidates for each of the above two error examples as in both cases hooks are created and connected. Here are the conditional statements that check for an EEXIST condition. ng_add_hook if (ng_findhook(node, name) != NULL) { ng_con_nodes if (ng_findhook(node2, name2) != NULL) { ng_con_part2 if (ng_findhook(node, NG_HOOK_NAME(hook)) != NULL) { In each of these cases, it appears that the code is checking to see if a hook with the argument name exists before creating a hook with that name. Given the conditions in the above two example errors that the hook names are unique and no hooks with these same names were previously created, I can't explain why the above calls to ng_findhook are returning references to hooks. Here are the hooks for one ng_nat(4) node of interest. At the time I obtained this information, this node was working correctly. Everything in this output looks correct. sudo ngctl show ipfw:202182138 Name: WirelessNAT2182138 Type: nat ID: 000062ee Num hooks: 2 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- in ipfw ipfw 00005a83 102182138 out ipfw ipfw 00005a83 202182138 sudo ngctl msg ipfw:102182138 listredirects Rec'd response "listredirects" (10) from "[62ee]:": Args: { total_count=1 redirects=[ { id=1 local_addr=10.10.118.43 alias_addr=136.152.182.138 proto=259 description="Static NAT" } ] } Running show on ipfw:102174202, I see that this hook is pointing to the above ng_nat(4) node WirelessNAT2182138. sudo ngctl show ipfw:102174202 Name: WirelessNAT2182138 Type: nat ID: 000062ee Num hooks: 2 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- in ipfw ipfw 00005a83 102182138 out ipfw ipfw 00005a83 202182138 But WirelessNAT2182138 has no record of a hook102174202. Somehow, two hooks used to refer to what should be two different NAT sessions are pointing to the same ng_nat(4) object (i.e. one session). If I run shutdown on ipfw:102174202, WirelessNAT2182138 goes away. Given the above calls to ngctl(8), I don't know what is causing these two separate hooks to refer to the same ng_nat(4) object. I welcome any suggestions for what other information I should collect to help debug this problem, ideas for fixing it, or corrections to my above statements. Thanks in advance, Erik From owner-freebsd-net@FreeBSD.ORG Thu Jan 14 23:02:02 2010 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 62EBB1065670 for ; Thu, 14 Jan 2010 23:02:02 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from mail-qy0-f174.google.com (mail-qy0-f174.google.com [209.85.221.174]) by mx1.freebsd.org (Postfix) with ESMTP id 121438FC0C for ; Thu, 14 Jan 2010 23:02:01 +0000 (UTC) Received: by qyk4 with SMTP id 4so79584qyk.7 for ; Thu, 14 Jan 2010 15:01:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=8j4hNn3WdUP5wZMjhviK0itvGRar2D5jSM8slXQk4qo=; b=i9xmto+2rtG8+v1VW/WNeFFgEDAkC8wfFr2WLraaPC2uATKkjBS5f8/+URS3uGzb1f AQGhG9GJ7T0DTuoPxMYAOsJf5HJIe+mxfVOVDjR7uYLpP6DLjbjaFVjpp4GYnUI3VyIM YZkwZniPLwI/eHKdxcNc3VlDMeypAIkX1M0rw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=m7qVBABicgCUvr5LAne+wmcA//LdcNgObkNLoYmX8RZp5EACvvsGw0gkr466qwjGsM Ha4YgeLhfoecoYRQBQSWbyCIMrYsawmhzOtsKwfKMqpms8P8ud8/jXlTBHHWR+5rmplu 4bN15sl6WonrJOQlvG9gpkdIzUvsENDQdG4wg= Received: by 10.224.123.129 with SMTP id p1mr1669463qar.28.1263510115457; Thu, 14 Jan 2010 15:01:55 -0800 (PST) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id 22sm1032540qyk.2.2010.01.14.15.01.53 (version=SSLv3 cipher=RC4-MD5); Thu, 14 Jan 2010 15:01:53 -0800 (PST) Received: by weongyo (sSMTP sendmail emulation); Thu, 14 Jan 2010 15:02:21 -0800 From: Weongyo Jeong Date: Thu, 14 Jan 2010 15:02:21 -0800 To: Kim Culhan Message-ID: <20100114230221.GZ1491@weongyo> Mail-Followup-To: Kim Culhan , freebsd-net@freebsd.org References: <89dbfdc31001141030m21aff1d2m41e9ac6e16c68b22@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89dbfdc31001141030m21aff1d2m41e9ac6e16c68b22@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: freebsd-net@freebsd.org Subject: Re: uath under FreeBSD 8.0-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 23:02:02 -0000 On Thu, Jan 14, 2010 at 01:30:47PM -0500, Kim Culhan wrote: > > On Thursday 24 December 2009 05:09:42 pm Weongyo Jeong wrote: > > Yesterday I ordered `Netgear Wireless USB Adapter WG111T' which probably > > is same one with you so I could reproduce your problem and debug it. > > Have you been successful so far ? Yes. Netgear Wireless USB Adapter WG111T in my environment worked well. Open or WPA associations are tested. Did you also encounter problems working with WG111T devices? regards, Weongyo Jeong From owner-freebsd-net@FreeBSD.ORG Fri Jan 15 00:22:35 2010 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 ABCB6106568B for ; Fri, 15 Jan 2010 00:22:35 +0000 (UTC) (envelope-from julian@elischer.org) Received: from utility-0.aerioconnect.net (utility-0.aerioconnect.net [216.240.32.11]) by mx1.freebsd.org (Postfix) with ESMTP id 91EB68FC12 for ; Fri, 15 Jan 2010 00:22:35 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by utility-0.aerioconnect.net (8.13.1/8.13.1) with ESMTP id o0F0MXDO027021; Thu, 14 Jan 2010 16:22:33 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id DD4192D6010; Thu, 14 Jan 2010 16:22:32 -0800 (PST) Message-ID: <4B4FB547.8000202@elischer.org> Date: Thu, 14 Jan 2010 16:22:31 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Erik Klavon References: <20100114224635.GA27139@malcolm.berkeley.edu> In-Reply-To: <20100114224635.GA27139@malcolm.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: netgraph mkpeer and connect failures with ng_ipfw and ng_nat 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, 15 Jan 2010 00:22:35 -0000 Erik Klavon wrote: > > Here are the hooks for one ng_nat(4) node of interest. At the time I > obtained this information, this node was working correctly. Everything > in this output looks correct. > > sudo ngctl show ipfw:202182138 > Name: WirelessNAT2182138 Type: nat ID: 000062ee Num hooks: 2 > Local hook Peer name Peer type Peer ID Peer hook > ---------- --------- --------- ------- --------- > in ipfw ipfw 00005a83 102182138 > out ipfw ipfw 00005a83 202182138 > > sudo ngctl msg ipfw:102182138 listredirects > Rec'd response "listredirects" (10) from "[62ee]:": > Args: { total_count=1 redirects=[ { id=1 local_addr=10.10.118.43 alias_addr=136.152.182.138 proto=259 description="Static NAT" } ] } > > Running show on ipfw:102174202, I see that this hook is pointing to > the above ng_nat(4) node WirelessNAT2182138. can you show that output? > > sudo ngctl show ipfw:102174202 > Name: WirelessNAT2182138 Type: nat ID: 000062ee Num hooks: 2 > Local hook Peer name Peer type Peer ID Peer hook > ---------- --------- --------- ------- --------- > in ipfw ipfw 00005a83 102182138 > out ipfw ipfw 00005a83 202182138 > > But WirelessNAT2182138 has no record of a hook102174202. Somehow, two > hooks used to refer to what should be two different NAT sessions are > pointing to the same ng_nat(4) object (i.e. one session). If I run > shutdown on ipfw:102174202, WirelessNAT2182138 goes away. Given the > above calls to ngctl(8), I don't know what is causing these two separate > hooks to refer to the same ng_nat(4) object. you might name the ipfw nodes to make the output clearer. I have not looked at the ipfw node type much but it is possible that is suffers from races. Especially in the face of ipfw rule changes. have you tried adding small delays (sleep 0.5) betwenn the calls by the way? From owner-freebsd-net@FreeBSD.ORG Fri Jan 15 00:54:04 2010 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 5359D106566C for ; Fri, 15 Jan 2010 00:54:04 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id E93C08FC0C for ; Fri, 15 Jan 2010 00:54:03 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 9so25952qwb.7 for ; Thu, 14 Jan 2010 16:54:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=CDe2SMXfERz0+pmT0quI6Ei+UOF1U/DJ4I8AgQmxbm8=; b=h1AWmlTAXZPT+2D6FV2bdONuJqwpPoUhEOwuGDoheDlgUhbI+9SJUrtE3xN0LHkMiB pIUPNmx149m+8tc+71cSzoIgvbE3w6nhwKyW+3McnANo6w+RRb3MTdrfOxoSuzA00HOO KayhXkUWbaVLYMZPCUakEkcbQLQiMs37YVd2g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=HRou3XHNZM6S3utErhl/1ix88E4aRmb9NxGZoBEvP26CX4ckommmLmmu4hvufpXFye /91y87cJVKnfva+3imhJ5KlJhu1fS52HCdd+nERlnzmZvxOy7Njz3fVoI6WjJjTl1tDt rBdNLYJbDP8DL+Hm7y9KPPxUDaZQA/A8Mzukw= Received: by 10.224.50.146 with SMTP id z18mr1688515qaf.216.1263516838624; Thu, 14 Jan 2010 16:53:58 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 26sm3321681qwa.10.2010.01.14.16.53.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 14 Jan 2010 16:53:57 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 14 Jan 2010 16:53:16 -0800 From: Pyun YongHyeon Date: Thu, 14 Jan 2010 16:53:16 -0800 To: Floris Bos Message-ID: <20100115005316.GB1228@michelle.cdnetworks.com> References: <201001140140.o0E1e5hr072464@freefall.freebsd.org> <201001142108.02941.info@je-eigen-domein.nl> <20100114201144.GA1228@michelle.cdnetworks.com> <201001142148.56444.info@je-eigen-domein.nl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="JkW1gnuWHDypiMFO" Content-Disposition: inline In-Reply-To: <201001142148.56444.info@je-eigen-domein.nl> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: kern/92090: [bge] bge: watchdog timeout -- resetting X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 00:54:04 -0000 --JkW1gnuWHDypiMFO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jan 14, 2010 at 09:48:56PM +0100, Floris Bos wrote: > On Thursday 14 January 2010 09:11:44 pm Pyun YongHyeon wrote: > > On Thu, Jan 14, 2010 at 09:08:02PM +0100, Floris Bos wrote: > > > On Thursday 14 January 2010 06:56:03 pm Pyun YongHyeon wrote: > > > > On Thu, Jan 14, 2010 at 04:33:19AM +0100, Floris Bos wrote: > > > > > Hi, > > > > > > > > > > On Thursday 14 January 2010 03:54:52 am Pyun YongHyeon wrote: > > > > > > > == > > > > > > > bge0: mem 0xdf900000-0xdf90ffff irq 16 at device 0.0 on pci32 > > > > > > > == > > > > > > > > > > > > > > After boot, the network works for about 5 seconds, barely enough time to get an IP by DHCP, and sent a ping or 2. > > > > > > > Then network connectivity goes down, and after some time there is a "bge0: watchdog timeout -- resetting" message. > > > > > > > > > > > > > > Then network works again for 5 seconds, and goes down again. All the time, repeatedly. > > > > > > > > > > > > > > The system works fine under Ubuntu. So I assume the hardware is ok. > > > > > > > > > > > > > > > > > > > I'm not sure but it looks like you have a BCM5784 controller. What is > > > > > > the output of "devinfo -rv | grep phy"? > > > > > > > > > > == > > > > > ukphy0 pnpinfo oui=0x50ef model=0x3a rev=0x4 at phyno=1 > > > > > ukphy1 pnpinfo oui=0x50ef model=0x3a rev=0x4 at phyno=1 > > > > > == > > > > > > > > Support for the PHY was added in r202269. > > > > Please try again after applying the change. Or you can download > > > > sys/dev/mii/miidevs and sys/dev/mii/brgphy.c from HEAD and rebuild > > > > kernel. > > > > > > Fetched the latest source using CVS on another computer, and transferred it to the system concerned by USB stick. > > > Rebuild the kernel, but the problem is still there. > > > > > Would you show me full dmesg output including "watchodg timeout" > > messages? > > === > Copyright (c) 1992-2010 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. [...] > bge0: mem 0xdf900000-0xdf90ffff irq 16 at device 0.0 on pci32 > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > bge0: Ethernet address: f4:ce:46:0f:2a:2c > bge0: [FILTER] > pcib4: irq 16 at device 28.5 on pci0 > pci34: on pcib4 > bge1: mem 0xdfa00000-0xdfa0ffff irq 17 at device 0.0 on pci34 > miibus1: on bge1 > brgphy1: PHY 1 on miibus1 > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > bge1: Ethernet address: f4:ce:46:0f:2a:2d > bge1: [FILTER] [...] Would you give attached patch try? I don't know whether it help or not though. I couldn't find any related information for possible clue of the issue in publicly available datasheet. --JkW1gnuWHDypiMFO Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="bge.clkreq.patch" Index: sys/dev/bge/if_bgereg.h =================================================================== --- sys/dev/bge/if_bgereg.h (revision 202295) +++ sys/dev/bge/if_bgereg.h (working copy) @@ -2615,6 +2615,7 @@ #define BGE_FLAG_5755_PLUS 0x00010000 #define BGE_FLAG_40BIT_BUG 0x00020000 #define BGE_FLAG_4G_BNDRY_BUG 0x00040000 +#define BGE_FLAG_CLKREQ_BUG 0x00080000 #define BGE_FLAG_RX_ALIGNBUG 0x00100000 #define BGE_FLAG_NO_3LED 0x00200000 #define BGE_FLAG_ADC_BUG 0x00400000 Index: sys/dev/bge/if_bge.c =================================================================== --- sys/dev/bge/if_bge.c (revision 202295) +++ sys/dev/bge/if_bge.c (working copy) @@ -898,9 +898,22 @@ { struct bge_softc *sc; struct mii_data *mii; + uint16_t link; + sc = device_get_softc(dev); mii = device_get_softc(sc->bge_miibus); + if ((sc->bge_flags & BGE_FLAG_CLKREQ_BUG) != 0) { + link = pci_read_config(dev, + sc->bge_expcap + PCIR_EXPRESS_LINK_CTL, 2); + if (IFM_SUBTYPE(mii->mii_media_active) == IFM_10_T || + IFM_SUBTYPE(mii->mii_media_active) == IFM_100_TX) + link &= ~0x0100; + else + link |= 0x0100; + pci_write_config(dev, + sc->bge_expcap + PCIR_EXPRESS_LINK_CTL, link, 2); + } BGE_CLRBIT(sc, BGE_MAC_MODE, BGE_MACMODE_PORTMODE); if (IFM_SUBTYPE(mii->mii_media_active) == IFM_1000_T || IFM_SUBTYPE(mii->mii_media_active) == IFM_1000_SX) @@ -2520,6 +2533,7 @@ struct ifnet *ifp; struct bge_softc *sc; uint32_t hwcfg = 0, misccfg; + uint16_t link; u_char eaddr[ETHER_ADDR_LEN]; int error, msicount, reg, rid, trys; @@ -2672,6 +2686,18 @@ */ sc->bge_flags |= BGE_FLAG_PCIE; sc->bge_expcap = reg; + link = pci_read_config(dev, reg + PCIR_EXPRESS_LINK_CTL, 2); + /* Check for CLKREQ. */ + if (link & 0x0100) { +#if 1 + device_printf(sc->bge_dev, "CLKREQ set!\n"); +#endif + if (sc->bge_asicrev == BGE_ASICREV_BCM5761 || + sc->bge_asicrev == BGE_ASICREV_BCM5784 || + sc->bge_chipid == BGE_CHIPID_BCM57780_A0 || + sc->bge_chipid == BGE_CHIPID_BCM57780_A1) + sc->bge_flags |= BGE_FLAG_CLKREQ_BUG; + } bge_set_max_readrq(sc); } else { /* --JkW1gnuWHDypiMFO-- From owner-freebsd-net@FreeBSD.ORG Fri Jan 15 01:42:56 2010 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 8FB1B1065679 for ; Fri, 15 Jan 2010 01:42:56 +0000 (UTC) (envelope-from erik@malcolm.berkeley.edu) Received: from malcolm.berkeley.edu (malcolm.Berkeley.EDU [IPv6:2607:f140:ffff:ffff::239]) by mx1.freebsd.org (Postfix) with ESMTP id 6E7C48FC12 for ; Fri, 15 Jan 2010 01:42:56 +0000 (UTC) Received: from malcolm.berkeley.edu (localhost [127.0.0.1]) by malcolm.berkeley.edu (8.14.3/8.13.8m1) with ESMTP id o0F1gsJ3029821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jan 2010 17:42:55 -0800 (PST) (envelope-from erik@malcolm.berkeley.edu) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at malcolm.berkeley.edu Received: (from erik@localhost) by malcolm.berkeley.edu (8.14.3/8.13.3/Submit) id o0F1gs0Y029820; Thu, 14 Jan 2010 17:42:54 -0800 (PST) (envelope-from erik) Date: Thu, 14 Jan 2010 17:42:54 -0800 From: Erik Klavon To: Julian Elischer Message-ID: <20100115014254.GA29258@malcolm.berkeley.edu> References: <20100114224635.GA27139@malcolm.berkeley.edu> <4B4FB547.8000202@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B4FB547.8000202@elischer.org> User-Agent: Mutt/1.4.2.3i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (malcolm.berkeley.edu [127.0.0.1]); Thu, 14 Jan 2010 17:42:55 -0800 (PST) Cc: freebsd-net@freebsd.org Subject: Re: netgraph mkpeer and connect failures with ng_ipfw and ng_nat 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, 15 Jan 2010 01:42:56 -0000 On Thu, Jan 14, 2010 at 04:22:31PM -0800, Julian Elischer wrote: > Erik Klavon wrote: > >Here are the hooks for one ng_nat(4) node of interest. At the time I > >obtained this information, this node was working correctly. Everything > >in this output looks correct. > > > >sudo ngctl show ipfw:202182138 > > Name: WirelessNAT2182138 Type: nat ID: 000062ee Num hooks: > > 2 > > Local hook Peer name Peer type Peer ID Peer hook > > ---------- --------- --------- ------- --------- > > in ipfw ipfw 00005a83 102182138 > > out ipfw ipfw 00005a83 202182138 > > > >sudo ngctl msg ipfw:102182138 listredirects > >Rec'd response "listredirects" (10) from "[62ee]:": > >Args: { total_count=1 redirects=[ { id=1 local_addr=10.10.118.43 > >alias_addr=136.152.182.138 proto=259 description="Static NAT" } ] } > > > >Running show on ipfw:102174202, I see that this hook is pointing to > >the above ng_nat(4) node WirelessNAT2182138. > > can you show that output? The output for ngctl show ipfw:102174202 is below. > >sudo ngctl show ipfw:102174202 > > Name: WirelessNAT2182138 Type: nat ID: 000062ee Num hooks: > > 2 > > Local hook Peer name Peer type Peer ID Peer hook > > ---------- --------- --------- ------- --------- > > in ipfw ipfw 00005a83 102182138 > > out ipfw ipfw 00005a83 202182138 > > > >But WirelessNAT2182138 has no record of a hook102174202. Somehow, two > >hooks used to refer to what should be two different NAT sessions are > >pointing to the same ng_nat(4) object (i.e. one session). If I run > >shutdown on ipfw:102174202, WirelessNAT2182138 goes away. Given the > >above calls to ngctl(8), I don't know what is causing these two separate > >hooks to refer to the same ng_nat(4) object. > > you might name the ipfw nodes to make the output clearer. ng_ipfw(4) uses a single node to pass traffic from ipfw(4) to netgraph(4). You associate as many hooks with this node as you like and then direct traffic via the single ng_ipfw(4) node to different hooks using ipfw(8) rules such as 01230 netgraph tablearg ip from table(87) to any in Suppose a packet comes in for IP address 10.10.113.226 and rule 1230 is reached during the processing of the ipfw ruleset. According to the above rule, ipfw(4) will look up 10.10.113.226/32 in table 87 and if it finds a matching key in the table, it will tag the packet with the matching table entry's value and send the packet to the ng_ipfw(4) node. ng_ipfw(4) will then examine the tag and look for an associated hook with a matching name. If such a hook is found the packet is sent on to the node associated with the hook. In the case of 10.10.113.226, table 87 contains the following entry. 10.10.113.226/32 202173114 Hook 202173114 refers to the following ng_nat node. sudo ngctl show ipfw:202173114 Name: WirelessNAT2173114 Type: nat ID: 000015f0 Num hooks: 2 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- in ipfw ipfw 00000001 102173114 out ipfw ipfw 00000001 202173114 which is configured for one to one NAT as follows. sudo ngctl msg WirelessNAT2173114: listredirects Rec'd response "listredirects" (10) from "[15f0]:": Args: { total_count=1 redirects=[ { id=1 local_addr=10.10.113.226 alias_addr=x.x.173.114 proto=259 description="Static NAT" } ] } There is a similar path for traffic coming in to the globally routable side of these one to one NAT nodes. > I have not looked at the ipfw node type much but it is possible > that is suffers from races. > Especially in the face of ipfw rule changes. Can you think of an example in any other netgraph module of proper concurrency handling I can use as a reference when looking at ng_ipfw(4)? By using tables we don't need to update the ruleset itself. The ruleset is (normally) loaded once after the machine boots. The table updates take place after all the calls to ngctl(8) and after the call to arp(8). I will take a look at the interface between ipfw(4) and ng_ipfw(4). > have you tried adding small delays (sleep 0.5) betwenn the calls by > the way? I've now added sleep 0.5 between the calls to ngctl. I'll let you know if that helps at all; thanks for the suggestion. Erik From owner-freebsd-net@FreeBSD.ORG Fri Jan 15 01:57:03 2010 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 7A15B106566C for ; Fri, 15 Jan 2010 01:57:03 +0000 (UTC) (envelope-from w8hdkim@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 45F078FC0C for ; Fri, 15 Jan 2010 01:57:03 +0000 (UTC) Received: by pxi13 with SMTP id 13so159175pxi.3 for ; Thu, 14 Jan 2010 17:57:02 -0800 (PST) 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 :content-transfer-encoding; bh=4HL2Mp7vN6V9aA56bq+NYN0jx1mll3aBIv/vclENuAs=; b=Bs5BGHxhvtI4ztoI9TzjYVwnMpH/Mr9s4I3C6+wHebcFYSum/nSE8ERgJLVZ2+Y56g VWrNrGW5J9gWbVdi6xXCBVqprnYdGNzV2AEA9ZpF3NQ3A2+nnTFJeP5p5KnkdAIxdRH+ i54AvyIFxfzK+pSleSL7HFUn+7EJkx783LOt4= 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:content-transfer-encoding; b=SC6XhfTyP/+1l0pJK5bM5I/pEusd+0UhVv47W2xIlSd94P7RYCl9cnvblsA/NRvfPD tKMliy2lVTr/5ze/w4BukDORfYA/KLGW5mxlMyh+HqioESsIG4/5LdGhvmIo+DYRSEjy 2PZoDePnXgYrGLQNrHwxZx7xBbj+ysh6RmtUc= MIME-Version: 1.0 Received: by 10.143.27.42 with SMTP id e42mr291858wfj.220.1263520622875; Thu, 14 Jan 2010 17:57:02 -0800 (PST) In-Reply-To: <20100114230221.GZ1491@weongyo> References: <89dbfdc31001141030m21aff1d2m41e9ac6e16c68b22@mail.gmail.com> <20100114230221.GZ1491@weongyo> Date: Thu, 14 Jan 2010 20:57:02 -0500 Message-ID: <89dbfdc31001141757l7a1e1a21v3171a3b14ece6d50@mail.gmail.com> From: Kim Culhan To: Weongyo Jeong , Kim Culhan , freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: uath under FreeBSD 8.0-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 01:57:03 -0000 On Thu, Jan 14, 2010 at 6:02 PM, Weongyo Jeong wr= ote: > On Thu, Jan 14, 2010 at 01:30:47PM -0500, Kim Culhan wrote: >> > On Thursday 24 December 2009 05:09:42 pm Weongyo Jeong wrote: >> > Yesterday I ordered `Netgear Wireless USB Adapter WG111T' which probab= ly >> > is same one with you so I could reproduce your problem and debug it. >> >> Have you been successful so far ? > > Yes. =A0Netgear Wireless USB Adapter WG111T in my environment worked well= . > Open or WPA associations are tested. =A0Did you also encounter problems > working with WG111T devices? No problem as I was waiting to see if you had success, now I am going to get one. thanks -kim From owner-freebsd-net@FreeBSD.ORG Fri Jan 15 02:27:00 2010 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 C78BF1065695 for ; Fri, 15 Jan 2010 02:27:00 +0000 (UTC) (envelope-from julian@elischer.org) Received: from utility-0.aerioconnect.net (utility-0.aerioconnect.net [216.240.32.11]) by mx1.freebsd.org (Postfix) with ESMTP id AB7718FC12 for ; Fri, 15 Jan 2010 02:27:00 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by utility-0.aerioconnect.net (8.13.1/8.13.1) with ESMTP id o0F2Qvax016246; Thu, 14 Jan 2010 18:26:57 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 36E5C2D6015; Thu, 14 Jan 2010 18:26:57 -0800 (PST) Message-ID: <4B4FD270.7010808@elischer.org> Date: Thu, 14 Jan 2010 18:26:56 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Erik Klavon References: <20100114224635.GA27139@malcolm.berkeley.edu> <4B4FB547.8000202@elischer.org> <20100115014254.GA29258@malcolm.berkeley.edu> In-Reply-To: <20100115014254.GA29258@malcolm.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: netgraph mkpeer and connect failures with ng_ipfw and ng_nat 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, 15 Jan 2010 02:27:00 -0000 Erik Klavon wrote: > On Thu, Jan 14, 2010 at 04:22:31PM -0800, Julian Elischer wrote: >> Erik Klavon wrote: >>> Here are the hooks for one ng_nat(4) node of interest. At the time I >>> obtained this information, this node was working correctly. Everything >>> in this output looks correct. >>> >>> sudo ngctl show ipfw:202182138 >>> Name: WirelessNAT2182138 Type: nat ID: 000062ee Num hooks: >>> 2 >>> Local hook Peer name Peer type Peer ID Peer hook >>> ---------- --------- --------- ------- --------- >>> in ipfw ipfw 00005a83 102182138 >>> out ipfw ipfw 00005a83 202182138 >>> >>> sudo ngctl msg ipfw:102182138 listredirects >>> Rec'd response "listredirects" (10) from "[62ee]:": >>> Args: { total_count=1 redirects=[ { id=1 local_addr=10.10.118.43 >>> alias_addr=136.152.182.138 proto=259 description="Static NAT" } ] } >>> >>> Running show on ipfw:102174202, I see that this hook is pointing to >>> the above ng_nat(4) node WirelessNAT2182138. >> can you show that output? > > The output for ngctl show ipfw:102174202 is below. how about the output for ipfw: ? > >>> sudo ngctl show ipfw:102174202 >>> Name: WirelessNAT2182138 Type: nat ID: 000062ee Num hooks: >>> 2 >>> Local hook Peer name Peer type Peer ID Peer hook >>> ---------- --------- --------- ------- --------- >>> in ipfw ipfw 00005a83 102182138 >>> out ipfw ipfw 00005a83 202182138 >>> >>> But WirelessNAT2182138 has no record of a hook102174202. Somehow, two >>> hooks used to refer to what should be two different NAT sessions are >>> pointing to the same ng_nat(4) object (i.e. one session). If I run >>> shutdown on ipfw:102174202, WirelessNAT2182138 goes away. Given the >>> above calls to ngctl(8), I don't know what is causing these two separate >>> hooks to refer to the same ng_nat(4) object. >> you might name the ipfw nodes to make the output clearer. > > ng_ipfw(4) uses a single node to pass traffic from ipfw(4) to > netgraph(4). You associate as many hooks with this node as you like and > then direct traffic via the single ng_ipfw(4) node to different hooks > using ipfw(8) rules such as > > 01230 netgraph tablearg ip from table(87) to any in > > Suppose a packet comes in for IP address 10.10.113.226 and rule 1230 > is reached during the processing of the ipfw ruleset. According to the > above rule, ipfw(4) will look up 10.10.113.226/32 in table 87 and if > it finds a matching key in the table, it will tag the packet with the > matching table entry's value and send the packet to the ng_ipfw(4) > node. ng_ipfw(4) will then examine the tag and look for an associated > hook with a matching name. If such a hook is found the packet is sent > on to the node associated with the hook. In the case of 10.10.113.226, > table 87 contains the following entry. > > 10.10.113.226/32 202173114 > > Hook 202173114 refers to the following ng_nat node. > > sudo ngctl show ipfw:202173114 > Name: WirelessNAT2173114 Type: nat ID: 000015f0 Num hooks: 2 > Local hook Peer name Peer type Peer ID Peer hook > ---------- --------- --------- ------- --------- > in ipfw ipfw 00000001 102173114 > out ipfw ipfw 00000001 202173114 > > which is configured for one to one NAT as follows. > > sudo ngctl msg WirelessNAT2173114: listredirects > Rec'd response "listredirects" (10) from "[15f0]:": > Args: { total_count=1 redirects=[ { id=1 local_addr=10.10.113.226 alias_addr=x.x.173.114 proto=259 description="Static NAT" } ] } > > There is a similar path for traffic coming in to the globally routable > side of these one to one NAT nodes. > >> I have not looked at the ipfw node type much but it is possible >> that is suffers from races. >> Especially in the face of ipfw rule changes. > > Can you think of an example in any other netgraph module of proper > concurrency handling I can use as a reference when looking at > ng_ipfw(4)? > > By using tables we don't need to update the ruleset itself. The > ruleset is (normally) loaded once after the machine boots. The table > updates take place after all the calls to ngctl(8) and after the call > to arp(8). I will take a look at the interface between ipfw(4) and > ng_ipfw(4). > >> have you tried adding small delays (sleep 0.5) betwenn the calls by >> the way? > > I've now added sleep 0.5 between the calls to ngctl. I'll let you know > if that helps at all; thanks for the suggestion. > > Erik From owner-freebsd-net@FreeBSD.ORG Fri Jan 15 02:34:03 2010 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 93226106566B for ; Fri, 15 Jan 2010 02:34:03 +0000 (UTC) (envelope-from info@je-eigen-domein.nl) Received: from mx2.je-eigen-domein.nl (mx2.je-eigen-domein.nl [85.10.196.86]) by mx1.freebsd.org (Postfix) with ESMTP id 2A0B78FC14 for ; Fri, 15 Jan 2010 02:34:02 +0000 (UTC) Received: from ubuntu.localnet (localhost [127.0.0.1]) by mx2.je-eigen-domein.nl (Postfix) with ESMTP id 1232178822A; Fri, 15 Jan 2010 03:34:14 +0100 (CET) From: Floris Bos Organization: Maxnet To: pyunyh@gmail.com Date: Fri, 15 Jan 2010 03:33:58 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <201001140140.o0E1e5hr072464@freefall.freebsd.org> <201001142148.56444.info@je-eigen-domein.nl> <20100115005316.GB1228@michelle.cdnetworks.com> In-Reply-To: <20100115005316.GB1228@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201001150333.59107.info@je-eigen-domein.nl> Cc: freebsd-net@freebsd.org Subject: Re: kern/92090: [bge] bge: watchdog timeout -- resetting 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, 15 Jan 2010 02:34:03 -0000 On Friday 15 January 2010 01:53:16 am Pyun YongHyeon wrote: > On Thu, Jan 14, 2010 at 09:48:56PM +0100, Floris Bos wrote: > > On Thursday 14 January 2010 09:11:44 pm Pyun YongHyeon wrote: > > > On Thu, Jan 14, 2010 at 09:08:02PM +0100, Floris Bos wrote: > > > > On Thursday 14 January 2010 06:56:03 pm Pyun YongHyeon wrote: > > > > > On Thu, Jan 14, 2010 at 04:33:19AM +0100, Floris Bos wrote: > > > > > > Hi, > > > > > > > > > > > > On Thursday 14 January 2010 03:54:52 am Pyun YongHyeon wrote: > > > > > > > > == > > > > > > > > bge0: mem 0xdf900000-0xdf90ffff irq 16 at device 0.0 on pci32 > > > > > > > > == > > > > > > > > > > > > > > > > After boot, the network works for about 5 seconds, barely enough time to get an IP by DHCP, and sent a ping or 2. > > > > > > > > Then network connectivity goes down, and after some time there is a "bge0: watchdog timeout -- resetting" message. > > > > > > > > > > > > > > > > Then network works again for 5 seconds, and goes down again. All the time, repeatedly. > > > > > > > > > > > > > > > > The system works fine under Ubuntu. So I assume the hardware is ok. > > > > > > > > > > > > > > > > > > > > > > I'm not sure but it looks like you have a BCM5784 controller. What is > > > > > > > the output of "devinfo -rv | grep phy"? > > > > > > > > > > > > == > > > > > > ukphy0 pnpinfo oui=0x50ef model=0x3a rev=0x4 at phyno=1 > > > > > > ukphy1 pnpinfo oui=0x50ef model=0x3a rev=0x4 at phyno=1 > > > > > > == > > > > > > > > > > Support for the PHY was added in r202269. > > > > > Please try again after applying the change. Or you can download > > > > > sys/dev/mii/miidevs and sys/dev/mii/brgphy.c from HEAD and rebuild > > > > > kernel. > > > > > > > > Fetched the latest source using CVS on another computer, and transferred it to the system concerned by USB stick. > > > > Rebuild the kernel, but the problem is still there. > > > > > > > Would you show me full dmesg output including "watchodg timeout" > > > messages? > > > > === > > Copyright (c) 1992-2010 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > [...] > > > bge0: mem 0xdf900000-0xdf90ffff irq 16 at device 0.0 on pci32 > > miibus0: on bge0 > > brgphy0: PHY 1 on miibus0 > > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > > bge0: Ethernet address: f4:ce:46:0f:2a:2c > > bge0: [FILTER] > > pcib4: irq 16 at device 28.5 on pci0 > > pci34: on pcib4 > > bge1: mem 0xdfa00000-0xdfa0ffff irq 17 at device 0.0 on pci34 > > miibus1: on bge1 > > brgphy1: PHY 1 on miibus1 > > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > > bge1: Ethernet address: f4:ce:46:0f:2a:2d > > bge1: [FILTER] > > [...] > > Would you give attached patch try? I don't know whether it help > or not though. I couldn't find any related information for possible > clue of the issue in publicly available datasheet. The patch did not make any difference. However I did notice something else odd. The problem only occurs on bge0, the second interface bge1 does work. I grabbed the U57DIAG diagnostic boot CD from the Broadcom site, and noticed that the first interface has ASF enabled, while the second one has not. I disabled ASF by doing: = b57udiag -cmd setasf -d == And now the first interface also works properly. So there is something with the ASF stuff that conflicts with FreeBSD. The IPMI card of the system is configured to use a dedicated 3rd LAN port, and is NOT sharing bge0. But perhaps the NIC is initialized differently nevertheless when ASF firmware is enabled, and that is causing issues? Yours sincerely, Floris Bos From owner-freebsd-net@FreeBSD.ORG Fri Jan 15 04:43:46 2010 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 81920106566C for ; Fri, 15 Jan 2010 04:43:46 +0000 (UTC) (envelope-from erik@malcolm.berkeley.edu) Received: from malcolm.berkeley.edu (malcolm.Berkeley.EDU [IPv6:2607:f140:ffff:ffff::239]) by mx1.freebsd.org (Postfix) with ESMTP id 6047A8FC08 for ; Fri, 15 Jan 2010 04:43:46 +0000 (UTC) Received: from malcolm.berkeley.edu (localhost [127.0.0.1]) by malcolm.berkeley.edu (8.14.3/8.13.8m1) with ESMTP id o0F4hiix031801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jan 2010 20:43:44 -0800 (PST) (envelope-from erik@malcolm.berkeley.edu) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at malcolm.berkeley.edu Received: (from erik@localhost) by malcolm.berkeley.edu (8.14.3/8.13.3/Submit) id o0F4hifJ031800; Thu, 14 Jan 2010 20:43:44 -0800 (PST) (envelope-from erik) Date: Thu, 14 Jan 2010 20:43:44 -0800 From: Erik Klavon To: Julian Elischer Message-ID: <20100115044344.GA30725@malcolm.berkeley.edu> References: <20100114224635.GA27139@malcolm.berkeley.edu> <4B4FB547.8000202@elischer.org> <20100115014254.GA29258@malcolm.berkeley.edu> <4B4FD270.7010808@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B4FD270.7010808@elischer.org> User-Agent: Mutt/1.4.2.3i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (malcolm.berkeley.edu [127.0.0.1]); Thu, 14 Jan 2010 20:43:44 -0800 (PST) Cc: freebsd-net@freebsd.org Subject: Re: netgraph mkpeer and connect failures with ng_ipfw and ng_nat 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, 15 Jan 2010 04:43:46 -0000 On Thu, Jan 14, 2010 at 06:26:56PM -0800, Julian Elischer wrote: > Erik Klavon wrote: > >On Thu, Jan 14, 2010 at 04:22:31PM -0800, Julian Elischer wrote: > >>Erik Klavon wrote: > >>>Here are the hooks for one ng_nat(4) node of interest. At the time I > >>>obtained this information, this node was working correctly. Everything > >>>in this output looks correct. > >>> > >>>sudo ngctl show ipfw:202182138 > >>> Name: WirelessNAT2182138 Type: nat ID: 000062ee Num > >>> hooks: 2 > >>> Local hook Peer name Peer type Peer ID Peer hook > >>> ---------- --------- --------- ------- --------- > >>> in ipfw ipfw 00005a83 102182138 > >>> out ipfw ipfw 00005a83 202182138 > >>> > >>>sudo ngctl msg ipfw:102182138 listredirects > >>>Rec'd response "listredirects" (10) from "[62ee]:": > >>>Args: { total_count=1 redirects=[ { id=1 local_addr=10.10.118.43 > >>>alias_addr=136.152.182.138 proto=259 description="Static NAT" } ] } > >>> > >>>Running show on ipfw:102174202, I see that this hook is pointing to > >>>the above ng_nat(4) node WirelessNAT2182138. > >>can you show that output? > > > >The output for ngctl show ipfw:102174202 is below. > > how about the output for ipfw: ? For that example (obtained a couple of days ago) I don't have output for show ipfw: recorded. I'll try to find a similar case tomorrow during the period of time when these problems occur. I'm currently collecting the output from the following commands every minute, in addition to all of the ngctl calls and output. /usr/bin/vmstat -mzs /usr/bin/netstat -m /usr/sbin/ngctl list /usr/sbin/ngctl show ipfw: /sbin/ipfw table 87 list /sbin/ipfw table 88 list >From today, here are examples of the mkpeer and connect errors with output from ngctl list and show just after the error. As in the earlier examples, each case is the first time the globally routable address was used since the machine booted. Jan 14 08:28:08 nac[70382]: /usr/sbin/ngctl -d mkpeer ipfw: nat 202174135 out Jan 14 08:28:08 nac[70388]: /usr/sbin/ngctl -d name ipfw:202174135 WirelessNAT2174135 Jan 14 08:28:08 nac[70394]: /usr/sbin/ngctl -d connect ipfw: WirelessNAT2174135: 102174135 in Jan 14 08:28:08 nac[70399]: ngctl: sendto(ipfw:): File exists Jan 14 08:28:08 nac[70399]: ngctl: send msg: File exists Thu Jan 14 08:29:01 PST 2010 /usr/sbin/ngctl list There are 62 total nodes: Name: WirelessNAT2132142 Type: nat ID: 0000019e Num hooks: 2 Name: WirelessNAT2172040 Type: nat ID: 000002ef Num hooks: 2 Name: WirelessNAT2173201 Type: nat ID: 000002c0 Num hooks: 2 Name: WirelessNAT2132017 Type: nat ID: 000001b2 Num hooks: 2 Name: WirelessNAT2183201 Type: nat ID: 0000023f Num hooks: 2 Name: WirelessNAT2183102 Type: nat ID: 000001c6 Num hooks: 2 Name: WirelessNAT2173220 Type: nat ID: 00000010 Num hooks: 2 Name: WirelessNAT2172132 Type: nat ID: 0000029f Num hooks: 2 Name: WirelessNAT2173033 Type: nat ID: 000002db Num hooks: 2 Name: WirelessNAT2183212 Type: nat ID: 000002b0 Num hooks: 2 Name: WirelessNAT2173025 Type: nat ID: 00000271 Num hooks: 2 Name: WirelessNAT2173061 Type: nat ID: 000001f2 Num hooks: 2 Name: WirelessNAT2132147 Type: nat ID: 000001e6 Num hooks: 2 Name: WirelessNAT2183051 Type: nat ID: 000001d0 Num hooks: 2 Name: WirelessNAT2172216 Type: nat ID: 000002cf Num hooks: 2 Name: WirelessNAT2182071 Type: nat ID: 0000020e Num hooks: 2 Name: WirelessNAT2183115 Type: nat ID: 000001ec Num hooks: 2 Name: WirelessNAT2182233 Type: nat ID: 000001d8 Num hooks: 2 Name: WirelessNAT2182009 Type: nat ID: 00000309 Num hooks: 2 Name: WirelessNAT2173144 Type: nat ID: 000002fd Num hooks: 2 Name: WirelessNAT2174107 Type: nat ID: 000002e3 Num hooks: 2 Name: WirelessNAT2173180 Type: nat ID: 0000027f Num hooks: 2 Name: WirelessNAT2173171 Type: nat ID: 00000279 Num hooks: 2 Name: WirelessNAT2172073 Type: nat ID: 00000208 Num hooks: 2 Name: WirelessNAT2182226 Type: nat ID: 0000030f Num hooks: 2 Name: WirelessNAT2174135 Type: nat ID: 00000305 Num hooks: 1 Name: WirelessNAT2183171 Type: nat ID: 000002f7 Num hooks: 2 Name: WirelessNAT2173235 Type: nat ID: 000002e9 Num hooks: 2 Name: WirelessNAT2175215 Type: nat ID: 0000028f Num hooks: 2 Name: WirelessNAT2172038 Type: nat ID: 00000263 Num hooks: 2 Name: WirelessNAT2175035 Type: nat ID: 0000025b Num hooks: 2 Name: WirelessNAT2172065 Type: nat ID: 000001a8 Num hooks: 2 Name: WirelessNAT2132096 Type: nat ID: 00000134 Num hooks: 2 Name: UnauthNat Type: nat ID: 00000004 Num hooks: 2 Name: WirelessNAT2175162 Type: nat ID: 00000315 Num hooks: 2 Name: WirelessNAT2183226 Type: nat ID: 000002d5 Num hooks: 2 Name: WirelessNAT2132178 Type: nat ID: 000002b8 Num hooks: 2 Name: WirelessNAT2175045 Type: nat ID: 00000297 Num hooks: 2 Name: WirelessNAT2182254 Type: nat ID: 00000255 Num hooks: 2 Name: WirelessNAT2132088 Type: nat ID: 00000245 Num hooks: 2 Name: WirelessNAT2183127 Type: nat ID: 00000228 Num hooks: 2 Name: WirelessNAT2173146 Type: nat ID: 0000021c Num hooks: 2 Name: WirelessNAT2183163 Type: nat ID: 00000198 Num hooks: 2 Name: WirelessNAT2172147 Type: nat ID: 00000188 Num hooks: 2 Name: WirelessNAT2182129 Type: nat ID: 000002c8 Num hooks: 2 Name: WirelessNAT2183173 Type: nat ID: 00000287 Num hooks: 2 Name: WirelessNAT2175064 Type: nat ID: 00000269 Num hooks: 2 Name: WirelessNAT2183083 Type: nat ID: 0000024f Num hooks: 2 Name: WirelessNAT2182255 Type: nat ID: 00000237 Num hooks: 2 Name: WirelessNAT2172085 Type: nat ID: 00000231 Num hooks: 2 Name: WirelessNAT2172157 Type: nat ID: 000001c0 Num hooks: 2 Name: WirelessNAT2174083 Type: nat ID: 000001ba Num hooks: 2 Name: WirelessNAT2173066 Type: nat ID: 00000174 Num hooks: 2 Name: WirelessNAT2132098 Type: nat ID: 0000016c Num hooks: 2 Name: WirelessNAT2173094 Type: nat ID: 00000190 Num hooks: 2 Name: WirelessNAT2173166 Type: nat ID: 00000154 Num hooks: 2 Name: WirelessNAT2183229 Type: nat ID: 00000126 Num hooks: 2 Name: WirelessNAT2173186 Type: nat ID: 00000200 Num hooks: 2 Name: WirelessNAT2175067 Type: nat ID: 000001f8 Num hooks: 2 Name: WirelessNAT2173179 Type: nat ID: 000002a8 Num hooks: 2 Name: ngctl73558 Type: socket ID: 0000031a Num hooks: 0 Name: ipfw Type: ipfw ID: 00000001 Num hooks: 119 /usr/sbin/ngctl show ipfw: Name: ipfw Type: ipfw ID: 00000001 Num hooks: 119 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- 102175162 WirelessNAT2175162 nat 00000315 in 202175162 WirelessNAT2175162 nat 00000315 out 102182226 WirelessNAT2182226 nat 0000030f in 202182226 WirelessNAT2182226 nat 0000030f out 102182009 WirelessNAT2182009 nat 00000309 in 202182009 WirelessNAT2182009 nat 00000309 out 202174135 WirelessNAT2174135 nat 00000305 out 102173144 WirelessNAT2173144 nat 000002fd in 202173144 WirelessNAT2173144 nat 000002fd out 102183171 WirelessNAT2183171 nat 000002f7 in 202183171 WirelessNAT2183171 nat 000002f7 out 102172040 WirelessNAT2172040 nat 000002ef in 202172040 WirelessNAT2172040 nat 000002ef out 102173235 WirelessNAT2173235 nat 000002e9 in 202173235 WirelessNAT2173235 nat 000002e9 out 102174107 WirelessNAT2174107 nat 000002e3 in 202174107 WirelessNAT2174107 nat 000002e3 out 102173033 WirelessNAT2173033 nat 000002db in 202173033 WirelessNAT2173033 nat 000002db out 102183226 WirelessNAT2183226 nat 000002d5 in 202183226 WirelessNAT2183226 nat 000002d5 out 102172216 WirelessNAT2172216 nat 000002cf in 202172216 WirelessNAT2172216 nat 000002cf out 102182129 WirelessNAT2182129 nat 000002c8 in 202182129 WirelessNAT2182129 nat 000002c8 out 102173201 WirelessNAT2173201 nat 000002c0 in 202173201 WirelessNAT2173201 nat 000002c0 out 102132178 WirelessNAT2132178 nat 000002b8 in 202132178 WirelessNAT2132178 nat 000002b8 out 102183212 WirelessNAT2183212 nat 000002b0 in 202183212 WirelessNAT2183212 nat 000002b0 out 102173179 WirelessNAT2173179 nat 000002a8 in 202173179 WirelessNAT2173179 nat 000002a8 out 102172132 WirelessNAT2172132 nat 0000029f in 202172132 WirelessNAT2172132 nat 0000029f out 102175045 WirelessNAT2175045 nat 00000297 in 202175045 WirelessNAT2175045 nat 00000297 out 102175215 WirelessNAT2175215 nat 0000028f in 202175215 WirelessNAT2175215 nat 0000028f out 102183173 WirelessNAT2183173 nat 00000287 in 202183173 WirelessNAT2183173 nat 00000287 out 102173180 WirelessNAT2173180 nat 0000027f in 202173180 WirelessNAT2173180 nat 0000027f out 102173171 WirelessNAT2173171 nat 00000279 in 202173171 WirelessNAT2173171 nat 00000279 out 102173025 WirelessNAT2173025 nat 00000271 in 202173025 WirelessNAT2173025 nat 00000271 out 102175064 WirelessNAT2175064 nat 00000269 in 202175064 WirelessNAT2175064 nat 00000269 out 102172038 WirelessNAT2172038 nat 00000263 in 202172038 WirelessNAT2172038 nat 00000263 out 102175035 WirelessNAT2175035 nat 0000025b in 202175035 WirelessNAT2175035 nat 0000025b out 102182254 WirelessNAT2182254 nat 00000255 in 202182254 WirelessNAT2182254 nat 00000255 out 102183083 WirelessNAT2183083 nat 0000024f in 202183083 WirelessNAT2183083 nat 0000024f out 102132088 WirelessNAT2132088 nat 00000245 in 202132088 WirelessNAT2132088 nat 00000245 out 102183201 WirelessNAT2183201 nat 0000023f in 202183201 WirelessNAT2183201 nat 0000023f out 102182255 WirelessNAT2182255 nat 00000237 in 202182255 WirelessNAT2182255 nat 00000237 out 102172085 WirelessNAT2172085 nat 00000231 in 202172085 WirelessNAT2172085 nat 00000231 out 102183127 WirelessNAT2183127 nat 00000228 in 202183127 WirelessNAT2183127 nat 00000228 out 102173146 WirelessNAT2173146 nat 0000021c in 202173146 WirelessNAT2173146 nat 0000021c out 102182071 WirelessNAT2182071 nat 0000020e in 202182071 WirelessNAT2182071 nat 0000020e out 102172073 WirelessNAT2172073 nat 00000208 in 202172073 WirelessNAT2172073 nat 00000208 out 102173186 WirelessNAT2173186 nat 00000200 in 202173186 WirelessNAT2173186 nat 00000200 out 102175067 WirelessNAT2175067 nat 000001f8 in 202175067 WirelessNAT2175067 nat 000001f8 out 102173061 WirelessNAT2173061 nat 000001f2 in 202173061 WirelessNAT2173061 nat 000001f2 out 102183115 WirelessNAT2183115 nat 000001ec in 202183115 WirelessNAT2183115 nat 000001ec out 102132147 WirelessNAT2132147 nat 000001e6 in 202132147 WirelessNAT2132147 nat 000001e6 out 102182233 WirelessNAT2182233 nat 000001d8 in 202182233 WirelessNAT2182233 nat 000001d8 out 102183051 WirelessNAT2183051 nat 000001d0 in 202183051 WirelessNAT2183051 nat 000001d0 out 102183102 WirelessNAT2183102 nat 000001c6 in 202183102 WirelessNAT2183102 nat 000001c6 out 102172157 WirelessNAT2172157 nat 000001c0 in 202172157 WirelessNAT2172157 nat 000001c0 out 102174083 WirelessNAT2174083 nat 000001ba in 202174083 WirelessNAT2174083 nat 000001ba out 102132017 WirelessNAT2132017 nat 000001b2 in 202132017 WirelessNAT2132017 nat 000001b2 out 102172065 WirelessNAT2172065 nat 000001a8 in 202172065 WirelessNAT2172065 nat 000001a8 out 102132142 WirelessNAT2132142 nat 0000019e in 202132142 WirelessNAT2132142 nat 0000019e out 102183163 WirelessNAT2183163 nat 00000198 in 202183163 WirelessNAT2183163 nat 00000198 out 102173094 WirelessNAT2173094 nat 00000190 in 202173094 WirelessNAT2173094 nat 00000190 out 102172147 WirelessNAT2172147 nat 00000188 in 202172147 WirelessNAT2172147 nat 00000188 out 102173066 WirelessNAT2173066 nat 00000174 in 202173066 WirelessNAT2173066 nat 00000174 out 102132098 WirelessNAT2132098 nat 0000016c in 202132098 WirelessNAT2132098 nat 0000016c out 102173166 WirelessNAT2173166 nat 00000154 in 202173166 WirelessNAT2173166 nat 00000154 out 102132096 WirelessNAT2132096 nat 00000134 in 202132096 WirelessNAT2132096 nat 00000134 out 102183229 WirelessNAT2183229 nat 00000126 in 202183229 WirelessNAT2183229 nat 00000126 out 102173220 WirelessNAT2173220 nat 00000010 in 202173220 WirelessNAT2173220 nat 00000010 out 1 UnauthNat nat 00000004 in 2 UnauthNat nat 00000004 out Jan 14 08:35:08 nac[3229]: /usr/sbin/ngctl -d mkpeer ipfw: nat 202183148 out Jan 14 08:35:08 nac[3234]: ngctl: sendto(ipfw:): File exists Jan 14 08:35:08 nac[3234]: ngctl: send msg: File exists Jan 14 08:35:08 nac[3235]: warning: Unsuccessful execution: /usr/sbin/ngctl -d mkpeer ipfw: nat 202183148 out Thu Jan 14 08:36:01 PST 2010 /usr/sbin/ngctl list There are 98 total nodes: Name: WirelessNAT2182100 Type: nat ID: 0000038a Num hooks: 2 Name: WirelessNAT2132070 Type: nat ID: 000003ca Num hooks: 2 Name: WirelessNAT2132142 Type: nat ID: 0000019e Num hooks: 2 Name: WirelessNAT2173111 Type: nat ID: 00000392 Num hooks: 2 Name: WirelessNAT2173012 Type: nat ID: 00000355 Num hooks: 2 Name: WirelessNAT2175100 Type: nat ID: 00000343 Num hooks: 2 Name: WirelessNAT2132062 Type: nat ID: 00000337 Num hooks: 2 Name: WirelessNAT2172040 Type: nat ID: 000002ef Num hooks: 2 Name: WirelessNAT2173201 Type: nat ID: 000002c0 Num hooks: 2 Name: WirelessNAT2132017 Type: nat ID: 000001b2 Num hooks: 2 Name: ngctl13132 Type: socket ID: 00000411 Num hooks: 0 Name: WirelessNAT2174111 Type: nat ID: 00000372 Num hooks: 2 Name: WirelessNAT2174210 Type: nat ID: 0000036a Num hooks: 2 Name: WirelessNAT2183201 Type: nat ID: 0000023f Num hooks: 2 Name: WirelessNAT2183102 Type: nat ID: 000001c6 Num hooks: 2 Name: WirelessNAT2173220 Type: nat ID: 00000010 Num hooks: 2 Name: WirelessNAT2174022 Type: nat ID: 00000406 Num hooks: 2 Name: WirelessNAT2132055 Type: nat ID: 000003e2 Num hooks: 2 Name: WirelessNAT2173023 Type: nat ID: 000003a6 Num hooks: 2 Name: WirelessNAT2172033 Type: nat ID: 0000039e Num hooks: 2 Name: WirelessNAT2172132 Type: nat ID: 0000029f Num hooks: 2 Name: WirelessNAT2132047 Type: nat ID: 000003fa Num hooks: 2 Name: WirelessNAT2182240 Type: nat ID: 00000329 Num hooks: 2 Name: WirelessNAT2174041 Type: nat ID: 0000031d Num hooks: 2 Name: WirelessNAT2173033 Type: nat ID: 000002db Num hooks: 2 Name: WirelessNAT2183212 Type: nat ID: 000002b0 Num hooks: 2 Name: WirelessNAT2132066 Type: nat ID: 00000398 Num hooks: 2 Name: WirelessNAT2173025 Type: nat ID: 00000271 Num hooks: 2 Name: WirelessNAT2173061 Type: nat ID: 000001f2 Num hooks: 2 Name: WirelessNAT2132147 Type: nat ID: 000001e6 Num hooks: 2 Name: WirelessNAT2183051 Type: nat ID: 000001d0 Num hooks: 2 Name: WirelessNAT2173143 Type: nat ID: 000003f4 Num hooks: 2 Name: WirelessNAT2175024 Type: nat ID: 000003ac Num hooks: 2 Name: WirelessNAT2172234 Type: nat ID: 00000363 Num hooks: 2 Name: WirelessNAT2173035 Type: nat ID: 0000034f Num hooks: 2 Name: WirelessNAT2172216 Type: nat ID: 000002cf Num hooks: 2 Name: WirelessNAT2182071 Type: nat ID: 0000020e Num hooks: 2 Name: WirelessNAT2183115 Type: nat ID: 000001ec Num hooks: 2 Name: WirelessNAT2182233 Type: nat ID: 000001d8 Num hooks: 2 Name: WirelessNAT2172037 Type: nat ID: 0000037e Num hooks: 2 Name: WirelessNAT2182009 Type: nat ID: 00000309 Num hooks: 2 Name: WirelessNAT2173144 Type: nat ID: 000002fd Num hooks: 2 Name: WirelessNAT2174107 Type: nat ID: 000002e3 Num hooks: 2 Name: WirelessNAT2173180 Type: nat ID: 0000027f Num hooks: 2 Name: WirelessNAT2172073 Type: nat ID: 00000208 Num hooks: 2 Name: WirelessNAT2175008 Type: nat ID: 000003e8 Num hooks: 2 Name: WirelessNAT2172236 Type: nat ID: 00000349 Num hooks: 2 Name: WirelessNAT2182226 Type: nat ID: 0000030f Num hooks: 2 Name: WirelessNAT2174135 Type: nat ID: 00000305 Num hooks: 1 Name: WirelessNAT2183171 Type: nat ID: 000002f7 Num hooks: 2 Name: WirelessNAT2173235 Type: nat ID: 000002e9 Num hooks: 2 Name: WirelessNAT2175215 Type: nat ID: 0000028f Num hooks: 2 Name: WirelessNAT2172038 Type: nat ID: 00000263 Num hooks: 2 Name: WirelessNAT2175035 Type: nat ID: 0000025b Num hooks: 2 Name: WirelessNAT2172065 Type: nat ID: 000001a8 Num hooks: 2 Name: WirelessNAT2132096 Type: nat ID: 00000134 Num hooks: 2 Name: UnauthNat Type: nat ID: 00000004 Num hooks: 2 Name: WirelessNAT2175072 Type: nat ID: 0000040c Num hooks: 2 Name: WirelessNAT2175081 Type: nat ID: 000003ee Num hooks: 2 Name: WirelessNAT2182173 Type: nat ID: 000003c4 Num hooks: 2 Name: WirelessNAT2183019 Type: nat ID: 0000033d Num hooks: 2 Name: WirelessNAT2175162 Type: nat ID: 00000315 Num hooks: 2 Name: WirelessNAT2183226 Type: nat ID: 000002d5 Num hooks: 2 Name: WirelessNAT2132178 Type: nat ID: 000002b8 Num hooks: 2 Name: WirelessNAT2175045 Type: nat ID: 00000297 Num hooks: 2 Name: WirelessNAT2182254 Type: nat ID: 00000255 Num hooks: 2 Name: WirelessNAT2132088 Type: nat ID: 00000245 Num hooks: 2 Name: WirelessNAT2183127 Type: nat ID: 00000228 Num hooks: 2 Name: WirelessNAT2173146 Type: nat ID: 0000021c Num hooks: 2 Name: WirelessNAT2183163 Type: nat ID: 00000198 Num hooks: 2 Name: WirelessNAT2172147 Type: nat ID: 00000188 Num hooks: 2 Name: WirelessNAT2174038 Type: nat ID: 0000032f Num hooks: 2 Name: WirelessNAT2182129 Type: nat ID: 000002c8 Num hooks: 2 Name: WirelessNAT2183173 Type: nat ID: 00000287 Num hooks: 2 Name: WirelessNAT2175064 Type: nat ID: 00000269 Num hooks: 2 Name: WirelessNAT2183083 Type: nat ID: 0000024f Num hooks: 2 Name: WirelessNAT2182255 Type: nat ID: 00000237 Num hooks: 2 Name: WirelessNAT2172085 Type: nat ID: 00000231 Num hooks: 2 Name: WirelessNAT2172157 Type: nat ID: 000001c0 Num hooks: 2 Name: WirelessNAT2174083 Type: nat ID: 000001ba Num hooks: 2 Name: WirelessNAT2173066 Type: nat ID: 00000174 Num hooks: 2 Name: WirelessNAT2132098 Type: nat ID: 0000016c Num hooks: 2 Name: WirelessNAT2183156 Type: nat ID: 00000400 Num hooks: 2 Name: WirelessNAT2182076 Type: nat ID: 00000384 Num hooks: 2 Name: WirelessNAT2175047 Type: nat ID: 00000323 Num hooks: 2 Name: WirelessNAT2173094 Type: nat ID: 00000190 Num hooks: 2 Name: WirelessNAT2173166 Type: nat ID: 00000154 Num hooks: 2 Name: WirelessNAT2183157 Type: nat ID: 000003d2 Num hooks: 2 Name: WirelessNAT2183229 Type: nat ID: 00000126 Num hooks: 2 Name: WirelessNAT2182195 Type: nat ID: 000003da Num hooks: 2 Name: WirelessNAT2173087 Type: nat ID: 000003be Num hooks: 2 Name: WirelessNAT2173186 Type: nat ID: 00000200 Num hooks: 2 Name: WirelessNAT2175067 Type: nat ID: 000001f8 Num hooks: 2 Name: WirelessNAT2182169 Type: nat ID: 00000378 Num hooks: 2 Name: WirelessNAT2172198 Type: nat ID: 0000035b Num hooks: 2 Name: WirelessNAT2173179 Type: nat ID: 000002a8 Num hooks: 2 Name: WirelessNAT2175098 Type: nat ID: 000003b2 Num hooks: 2 Name: ipfw Type: ipfw ID: 00000001 Num hooks: 191 /usr/sbin/ngctl show ipfw: Name: ipfw Type: ipfw ID: 00000001 Num hooks: 191 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- 102175072 WirelessNAT2175072 nat 0000040c in 202175072 WirelessNAT2175072 nat 0000040c out 102174022 WirelessNAT2174022 nat 00000406 in 202174022 WirelessNAT2174022 nat 00000406 out 102183156 WirelessNAT2183156 nat 00000400 in 202183156 WirelessNAT2183156 nat 00000400 out 102132047 WirelessNAT2132047 nat 000003fa in 202132047 WirelessNAT2132047 nat 000003fa out 102173143 WirelessNAT2173143 nat 000003f4 in 202173143 WirelessNAT2173143 nat 000003f4 out 102175081 WirelessNAT2175081 nat 000003ee in 202175081 WirelessNAT2175081 nat 000003ee out 102175008 WirelessNAT2175008 nat 000003e8 in 202175008 WirelessNAT2175008 nat 000003e8 out 102132055 WirelessNAT2132055 nat 000003e2 in 202132055 WirelessNAT2132055 nat 000003e2 out 102182195 WirelessNAT2182195 nat 000003da in 202182195 WirelessNAT2182195 nat 000003da out 102183157 WirelessNAT2183157 nat 000003d2 in 202183157 WirelessNAT2183157 nat 000003d2 out 102132070 WirelessNAT2132070 nat 000003ca in 202132070 WirelessNAT2132070 nat 000003ca out 102182173 WirelessNAT2182173 nat 000003c4 in 202182173 WirelessNAT2182173 nat 000003c4 out 102173087 WirelessNAT2173087 nat 000003be in 202173087 WirelessNAT2173087 nat 000003be out 102175098 WirelessNAT2175098 nat 000003b2 in 202175098 WirelessNAT2175098 nat 000003b2 out 102175024 WirelessNAT2175024 nat 000003ac in 202175024 WirelessNAT2175024 nat 000003ac out 102173023 WirelessNAT2173023 nat 000003a6 in 202173023 WirelessNAT2173023 nat 000003a6 out 102172033 WirelessNAT2172033 nat 0000039e in 202172033 WirelessNAT2172033 nat 0000039e out 102132066 WirelessNAT2132066 nat 00000398 in 202132066 WirelessNAT2132066 nat 00000398 out 102173111 WirelessNAT2173111 nat 00000392 in 202173111 WirelessNAT2173111 nat 00000392 out 102182100 WirelessNAT2182100 nat 0000038a in 202182100 WirelessNAT2182100 nat 0000038a out 102182076 WirelessNAT2182076 nat 00000384 in 202182076 WirelessNAT2182076 nat 00000384 out 102172037 WirelessNAT2172037 nat 0000037e in 202172037 WirelessNAT2172037 nat 0000037e out 102182169 WirelessNAT2182169 nat 00000378 in 202182169 WirelessNAT2182169 nat 00000378 out 102174111 WirelessNAT2174111 nat 00000372 in 202174111 WirelessNAT2174111 nat 00000372 out 102174210 WirelessNAT2174210 nat 0000036a in 202174210 WirelessNAT2174210 nat 0000036a out 102172234 WirelessNAT2172234 nat 00000363 in 202172234 WirelessNAT2172234 nat 00000363 out 102172198 WirelessNAT2172198 nat 0000035b in 202172198 WirelessNAT2172198 nat 0000035b out 102173012 WirelessNAT2173012 nat 00000355 in 202173012 WirelessNAT2173012 nat 00000355 out 102173035 WirelessNAT2173035 nat 0000034f in 202173035 WirelessNAT2173035 nat 0000034f out 102172236 WirelessNAT2172236 nat 00000349 in 202172236 WirelessNAT2172236 nat 00000349 out 102175100 WirelessNAT2175100 nat 00000343 in 202175100 WirelessNAT2175100 nat 00000343 out 102183019 WirelessNAT2183019 nat 0000033d in 202183019 WirelessNAT2183019 nat 0000033d out 102132062 WirelessNAT2132062 nat 00000337 in 202132062 WirelessNAT2132062 nat 00000337 out 102174038 WirelessNAT2174038 nat 0000032f in 202174038 WirelessNAT2174038 nat 0000032f out 102182240 WirelessNAT2182240 nat 00000329 in 202182240 WirelessNAT2182240 nat 00000329 out 102175047 WirelessNAT2175047 nat 00000323 in 202175047 WirelessNAT2175047 nat 00000323 out 102174041 WirelessNAT2174041 nat 0000031d in 202174041 WirelessNAT2174041 nat 0000031d out 102175162 WirelessNAT2175162 nat 00000315 in 202175162 WirelessNAT2175162 nat 00000315 out 102182226 WirelessNAT2182226 nat 0000030f in 202182226 WirelessNAT2182226 nat 0000030f out 102182009 WirelessNAT2182009 nat 00000309 in 202182009 WirelessNAT2182009 nat 00000309 out 202174135 WirelessNAT2174135 nat 00000305 out 102173144 WirelessNAT2173144 nat 000002fd in 202173144 WirelessNAT2173144 nat 000002fd out 102183171 WirelessNAT2183171 nat 000002f7 in 202183171 WirelessNAT2183171 nat 000002f7 out 102172040 WirelessNAT2172040 nat 000002ef in 202172040 WirelessNAT2172040 nat 000002ef out 102173235 WirelessNAT2173235 nat 000002e9 in 202173235 WirelessNAT2173235 nat 000002e9 out 102174107 WirelessNAT2174107 nat 000002e3 in 202174107 WirelessNAT2174107 nat 000002e3 out 102173033 WirelessNAT2173033 nat 000002db in 202173033 WirelessNAT2173033 nat 000002db out 102183226 WirelessNAT2183226 nat 000002d5 in 202183226 WirelessNAT2183226 nat 000002d5 out 102172216 WirelessNAT2172216 nat 000002cf in 202172216 WirelessNAT2172216 nat 000002cf out 102182129 WirelessNAT2182129 nat 000002c8 in 202182129 WirelessNAT2182129 nat 000002c8 out 102173201 WirelessNAT2173201 nat 000002c0 in 202173201 WirelessNAT2173201 nat 000002c0 out 102132178 WirelessNAT2132178 nat 000002b8 in 202132178 WirelessNAT2132178 nat 000002b8 out 102183212 WirelessNAT2183212 nat 000002b0 in 202183212 WirelessNAT2183212 nat 000002b0 out 102173179 WirelessNAT2173179 nat 000002a8 in 202173179 WirelessNAT2173179 nat 000002a8 out 102172132 WirelessNAT2172132 nat 0000029f in 202172132 WirelessNAT2172132 nat 0000029f out 102175045 WirelessNAT2175045 nat 00000297 in 202175045 WirelessNAT2175045 nat 00000297 out 102175215 WirelessNAT2175215 nat 0000028f in 202175215 WirelessNAT2175215 nat 0000028f out 102183173 WirelessNAT2183173 nat 00000287 in 202183173 WirelessNAT2183173 nat 00000287 out 102173180 WirelessNAT2173180 nat 0000027f in 202173180 WirelessNAT2173180 nat 0000027f out 102173025 WirelessNAT2173025 nat 00000271 in 202173025 WirelessNAT2173025 nat 00000271 out 102175064 WirelessNAT2175064 nat 00000269 in 202175064 WirelessNAT2175064 nat 00000269 out 102172038 WirelessNAT2172038 nat 00000263 in 202172038 WirelessNAT2172038 nat 00000263 out 102175035 WirelessNAT2175035 nat 0000025b in 202175035 WirelessNAT2175035 nat 0000025b out 102182254 WirelessNAT2182254 nat 00000255 in 202182254 WirelessNAT2182254 nat 00000255 out 102183083 WirelessNAT2183083 nat 0000024f in 202183083 WirelessNAT2183083 nat 0000024f out 102132088 WirelessNAT2132088 nat 00000245 in 202132088 WirelessNAT2132088 nat 00000245 out 102183201 WirelessNAT2183201 nat 0000023f in 202183201 WirelessNAT2183201 nat 0000023f out 102182255 WirelessNAT2182255 nat 00000237 in 202182255 WirelessNAT2182255 nat 00000237 out 102172085 WirelessNAT2172085 nat 00000231 in 202172085 WirelessNAT2172085 nat 00000231 out 102183127 WirelessNAT2183127 nat 00000228 in 202183127 WirelessNAT2183127 nat 00000228 out 102173146 WirelessNAT2173146 nat 0000021c in 202173146 WirelessNAT2173146 nat 0000021c out 102182071 WirelessNAT2182071 nat 0000020e in 202182071 WirelessNAT2182071 nat 0000020e out 102172073 WirelessNAT2172073 nat 00000208 in 202172073 WirelessNAT2172073 nat 00000208 out 102173186 WirelessNAT2173186 nat 00000200 in 202173186 WirelessNAT2173186 nat 00000200 out 102175067 WirelessNAT2175067 nat 000001f8 in 202175067 WirelessNAT2175067 nat 000001f8 out 102173061 WirelessNAT2173061 nat 000001f2 in 202173061 WirelessNAT2173061 nat 000001f2 out 102183115 WirelessNAT2183115 nat 000001ec in 202183115 WirelessNAT2183115 nat 000001ec out 102132147 WirelessNAT2132147 nat 000001e6 in 202132147 WirelessNAT2132147 nat 000001e6 out 102182233 WirelessNAT2182233 nat 000001d8 in 202182233 WirelessNAT2182233 nat 000001d8 out 102183051 WirelessNAT2183051 nat 000001d0 in 202183051 WirelessNAT2183051 nat 000001d0 out 102183102 WirelessNAT2183102 nat 000001c6 in 202183102 WirelessNAT2183102 nat 000001c6 out 102172157 WirelessNAT2172157 nat 000001c0 in 202172157 WirelessNAT2172157 nat 000001c0 out 102174083 WirelessNAT2174083 nat 000001ba in 202174083 WirelessNAT2174083 nat 000001ba out 102132017 WirelessNAT2132017 nat 000001b2 in 202132017 WirelessNAT2132017 nat 000001b2 out 102172065 WirelessNAT2172065 nat 000001a8 in 202172065 WirelessNAT2172065 nat 000001a8 out 102132142 WirelessNAT2132142 nat 0000019e in 202132142 WirelessNAT2132142 nat 0000019e out 102183163 WirelessNAT2183163 nat 00000198 in 202183163 WirelessNAT2183163 nat 00000198 out 102173094 WirelessNAT2173094 nat 00000190 in 202173094 WirelessNAT2173094 nat 00000190 out 102172147 WirelessNAT2172147 nat 00000188 in 202172147 WirelessNAT2172147 nat 00000188 out 102173066 WirelessNAT2173066 nat 00000174 in 202173066 WirelessNAT2173066 nat 00000174 out 102132098 WirelessNAT2132098 nat 0000016c in 202132098 WirelessNAT2132098 nat 0000016c out 102173166 WirelessNAT2173166 nat 00000154 in 202173166 WirelessNAT2173166 nat 00000154 out 102132096 WirelessNAT2132096 nat 00000134 in 202132096 WirelessNAT2132096 nat 00000134 out 102183229 WirelessNAT2183229 nat 00000126 in 202183229 WirelessNAT2183229 nat 00000126 out 102173220 WirelessNAT2173220 nat 00000010 in 202173220 WirelessNAT2173220 nat 00000010 out 1 UnauthNat nat 00000004 in 2 UnauthNat nat 00000004 out > >>>sudo ngctl show ipfw:102174202 > >>> Name: WirelessNAT2182138 Type: nat ID: 000062ee Num > >>> hooks: 2 > >>> Local hook Peer name Peer type Peer ID Peer hook > >>> ---------- --------- --------- ------- --------- > >>> in ipfw ipfw 00005a83 102182138 > >>> out ipfw ipfw 00005a83 202182138 > >>> > >>>But WirelessNAT2182138 has no record of a hook102174202. Somehow, two > >>>hooks used to refer to what should be two different NAT sessions are > >>>pointing to the same ng_nat(4) object (i.e. one session). If I run > >>>shutdown on ipfw:102174202, WirelessNAT2182138 goes away. Given the > >>>above calls to ngctl(8), I don't know what is causing these two separate > >>>hooks to refer to the same ng_nat(4) object. > >>you might name the ipfw nodes to make the output clearer. > > > >ng_ipfw(4) uses a single node to pass traffic from ipfw(4) to > >netgraph(4). You associate as many hooks with this node as you like and > >then direct traffic via the single ng_ipfw(4) node to different hooks > >using ipfw(8) rules such as > > > >01230 netgraph tablearg ip from table(87) to any in > > > >Suppose a packet comes in for IP address 10.10.113.226 and rule 1230 > >is reached during the processing of the ipfw ruleset. According to the > >above rule, ipfw(4) will look up 10.10.113.226/32 in table 87 and if > >it finds a matching key in the table, it will tag the packet with the > >matching table entry's value and send the packet to the ng_ipfw(4) > >node. ng_ipfw(4) will then examine the tag and look for an associated > >hook with a matching name. If such a hook is found the packet is sent > >on to the node associated with the hook. In the case of 10.10.113.226, > >table 87 contains the following entry. > > > >10.10.113.226/32 202173114 > > > >Hook 202173114 refers to the following ng_nat node. > > > >sudo ngctl show ipfw:202173114 > > Name: WirelessNAT2173114 Type: nat ID: 000015f0 Num hooks: > > 2 > > Local hook Peer name Peer type Peer ID Peer hook > > ---------- --------- --------- ------- --------- > > in ipfw ipfw 00000001 102173114 > > out ipfw ipfw 00000001 202173114 > > > >which is configured for one to one NAT as follows. > > > >sudo ngctl msg WirelessNAT2173114: listredirects > >Rec'd response "listredirects" (10) from "[15f0]:": > >Args: { total_count=1 redirects=[ { id=1 local_addr=10.10.113.226 > >alias_addr=x.x.173.114 proto=259 description="Static NAT" } ] } > > > >There is a similar path for traffic coming in to the globally routable > >side of these one to one NAT nodes. > > > >>I have not looked at the ipfw node type much but it is possible > >>that is suffers from races. > >>Especially in the face of ipfw rule changes. > > > >Can you think of an example in any other netgraph module of proper > >concurrency handling I can use as a reference when looking at > >ng_ipfw(4)? > > > >By using tables we don't need to update the ruleset itself. The > >ruleset is (normally) loaded once after the machine boots. The table > >updates take place after all the calls to ngctl(8) and after the call > >to arp(8). I will take a look at the interface between ipfw(4) and > >ng_ipfw(4). > > > >>have you tried adding small delays (sleep 0.5) betwenn the calls by > >>the way? > > > >I've now added sleep 0.5 between the calls to ngctl. I'll let you know > >if that helps at all; thanks for the suggestion. From owner-freebsd-net@FreeBSD.ORG Fri Jan 15 07:30:05 2010 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 05030106566B for ; Fri, 15 Jan 2010 07:30: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 E3A488FC17 for ; Fri, 15 Jan 2010 07:30: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 o0F7U4kI088100 for ; Fri, 15 Jan 2010 07:30:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0F7U4AM088096; Fri, 15 Jan 2010 07:30:04 GMT (envelope-from gnats) Date: Fri, 15 Jan 2010 07:30:04 GMT Message-Id: <201001150730.o0F7U4AM088096@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Andre Albsmeier Cc: Subject: Re: kern/142018: [iwi] [patch] Possibly wrong interpretation of beacon->number in if_iwi.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andre Albsmeier List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 07:30:05 -0000 The following reply was made to PR kern/142018; it has been noted by GNATS. From: Andre Albsmeier To: Bernhard Schmidt Cc: bug-followup@freebsd.org, Andre.Albsmeier@siemens.com Subject: Re: kern/142018: [iwi] [patch] Possibly wrong interpretation of beacon->number in if_iwi.c Date: Fri, 15 Jan 2010 08:07:40 +0100 On Thu, 14-Jan-2010 at 16:10:28 +0100, Bernhard Schmidt wrote: > Hi, > > It might be simple endianess related issue, does this patch make any > difference? No, it doesn't (which is what I expected on an i386 machine). And beacon->state is not the problem, it's beacon->number ;-) If have associated the interface to a network with a weak signal and results are the same: Jan 15 08:00:08 box kernel: Beacon state (1, 0x1260606) Jan 15 08:00:09 box kernel: Beacon state (1, 0x1260707) Jan 15 08:00:09 box kernel: Beacon state (1, 0x1260808) Jan 15 08:00:09 box kernel: Beacon state (1, 0x1260606) Jan 15 08:00:10 box kernel: Beacon state (1, 0x1260707) Jan 15 08:00:10 box kernel: Beacon state (1, 0x1260808) Jan 15 08:00:10 box kernel: Beacon state (1, 0x1260909) Jan 15 08:00:10 box kernel: Beacon state (1, 0x1260a0a) Jan 15 08:00:10 box kernel: Beacon state (1, 0x1260b0b) Jan 15 08:00:12 box kernel: Beacon state (1, 0x1260606) Jan 15 08:00:12 box kernel: Beacon state (1, 0x1260707) Jan 15 08:00:12 box kernel: Beacon state (1, 0x1260808) Jan 15 08:00:12 box kernel: Beacon state (1, 0x1260909) Jan 15 08:00:13 box kernel: Beacon state (1, 0x1260a0a) Jan 15 08:00:13 box kernel: Beacon state (1, 0x1260b0b) Jan 15 08:00:15 box kernel: Beacon state (1, 0x210606) Jan 15 08:00:15 box kernel: Beacon state (1, 0x210707) Jan 15 08:00:15 box kernel: Beacon state (1, 0x210808) Jan 15 08:00:15 box kernel: Beacon state (1, 0x210909) Jan 15 08:00:15 box kernel: Beacon state (1, 0x210a0a) Jan 15 08:00:15 box kernel: Beacon state (1, 0x210b0b) Jan 15 08:00:18 box kernel: Beacon state (1, 0x606) Jan 15 08:00:18 box kernel: Beacon state (1, 0x707) Jan 15 08:00:18 box kernel: Beacon state (1, 0x808) Jan 15 08:00:18 box kernel: Beacon state (1, 0x909) Jan 15 08:00:18 box kernel: Beacon state (1, 0xa0a) Jan 15 08:00:18 box kernel: Beacon state (1, 0xb0b) Jan 15 08:00:21 box kernel: Beacon state (1, 0x606) Jan 15 08:00:21 box kernel: Beacon state (1, 0x707) Jan 15 08:00:21 box kernel: Beacon state (1, 0x808) Jan 15 08:00:21 box kernel: Beacon state (1, 0x909) Jan 15 08:00:21 box kernel: Beacon state (1, 0xa0a) Jan 15 08:00:21 box kernel: Beacon state (1, 0xb0b) Jan 15 08:00:24 box kernel: Beacon state (1, 0x606) Jan 15 08:00:25 box kernel: Beacon state (1, 0x707) Jan 15 08:00:25 box kernel: Beacon state (1, 0x808) Jan 15 08:00:25 box kernel: Beacon state (1, 0x909) Jan 15 08:00:25 box kernel: Beacon state (1, 0xa0a) Jan 15 08:00:25 box kernel: Beacon state (1, 0xb0b) Jan 15 08:00:27 box kernel: Beacon state (1, 0x606) Jan 15 08:00:27 box kernel: Beacon state (1, 0x707) Jan 15 08:00:28 box kernel: Beacon state (1, 0x808) Jan 15 08:00:29 box kernel: Beacon state (1, 0x1220606) Jan 15 08:00:29 box kernel: Beacon state (1, 0x1220707) Jan 15 08:00:30 box kernel: Beacon state (1, 0x1220808) Jan 15 08:00:30 box kernel: Beacon state (1, 0x1220909) Jan 15 08:00:30 box kernel: Beacon state (1, 0x1220a0a) Jan 15 08:00:30 box kernel: Beacon state (1, 0x1220b0b) -Andre > > Index: if_iwi.c > =================================================================== > --- sys/dev/iwi/if_iwi.c (revision 202285) > +++ sys/dev/iwi/if_iwi.c (working copy) > @@ -1499,9 +1499,9 @@ iwi_notification_intr(struct iwi_softc *sc, struct > beacon = (struct iwi_notif_beacon_state *)(notif + 1); > > DPRINTFN(5, ("Beacon state (%u, %u)\n", > - beacon->state, le32toh(beacon->number))); > + le32toh(beacon->state), le32toh(beacon->number))); > > - if (beacon->state == IWI_BEACON_MISS) { > + if (le32toh(beacon->state) == IWI_BEACON_MISS) { > /* > * The firmware notifies us of every beacon miss > * so we need to track the count against the > > -- > Bernhard From owner-freebsd-net@FreeBSD.ORG Fri Jan 15 09:28:33 2010 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 38298106566B for ; Fri, 15 Jan 2010 09:28:33 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from mailrelay1.rambler.ru (mailrelay1.rambler.ru [81.19.66.239]) by mx1.freebsd.org (Postfix) with ESMTP id BF69D8FC14 for ; Fri, 15 Jan 2010 09:28:32 +0000 (UTC) Received: from kas30pipe.localhost (localhost [127.0.0.1]) by mailrelay1.rambler.ru (Postfix) with ESMTP id 8FC99130C70; Fri, 15 Jan 2010 12:28:31 +0300 (MSK) Received: from localhost (sysoev.ru [81.19.68.137]) by mailrelay1.rambler.ru (Postfix) with ESMTP id 02150130C67; Fri, 15 Jan 2010 12:28:31 +0300 (MSK) Date: Fri, 15 Jan 2010 12:28:30 +0300 From: Igor Sysoev To: Pyun YongHyeon Message-ID: <20100115092830.GF84494@rambler-co.ru> References: <20091204075440.GH14822@rambler-co.ru> <20091204173243.GC16491@michelle.cdnetworks.com> <20091204191114.GB76992@rambler-co.ru> <20091204195140.GH16491@michelle.cdnetworks.com> <20091204201303.GD76992@rambler-co.ru> <20091204202213.GI16491@michelle.cdnetworks.com> <20100114160333.GC16657@rambler-co.ru> <20100114181031.GX1228@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20100114181031.GX1228@michelle.cdnetworks.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Anti-Virus: Kaspersky Anti-Virus for MailServers 5.5.33/RELEASE, bases: 02092009 #2738642, status: clean X-SpamTest-Envelope-From: is@rambler-co.ru X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 9536 [Sen 02 2009] X-SpamTest-Info: {HEADERS: header Content-Type found without required header Content-Transfer-Encoding} X-SpamTest-Method: none X-SpamTest-Rate: 10 X-SpamTest-SPF: pass X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release Cc: freebsd-net@freebsd.org Subject: Re: hw.bge.forced_collapse 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, 15 Jan 2010 09:28:33 -0000 On Thu, Jan 14, 2010 at 10:10:31AM -0800, Pyun YongHyeon wrote: > On Thu, Jan 14, 2010 at 07:03:33PM +0300, Igor Sysoev wrote: > > On Fri, Dec 04, 2009 at 12:22:13PM -0800, Pyun YongHyeon wrote: > > > > > On Fri, Dec 04, 2009 at 11:13:03PM +0300, Igor Sysoev wrote: > > > > On Fri, Dec 04, 2009 at 11:51:40AM -0800, Pyun YongHyeon wrote: > > > > > > > > > On Fri, Dec 04, 2009 at 10:11:14PM +0300, Igor Sysoev wrote: > > > > > > On Fri, Dec 04, 2009 at 09:32:43AM -0800, Pyun YongHyeon wrote: > > > > > > > > > > > > > On Fri, Dec 04, 2009 at 10:54:40AM +0300, Igor Sysoev wrote: > > > > > > > > I saw commit introducing hw.bge.forced_collapse loader tunable. > > > > > > > > Just intresting, why it can not be a sysctl ? > > > > > > > > > > > > > > I didn't think the sysctl variable would be frequently changed > > > > > > > in runtime except debugging driver so I took simple path. > > > > > > > > > > > > I do not think it's worth to reboot server just to look how various > > > > > > values affect on bandwidth and CPU usage, expecially in production. > > > > > > > > > > > > As I understand the change is trivial: > > > > > > > > > > > > - CTLFLAG_RD > > > > > > + CTLFLAG_RW > > > > > > > > > > > > since bge_forced_collapse is used atomically. > > > > > > > > > > > > > > > > I have no problem changing it to RW but that case I may have to > > > > > create actual sysctl node(e.g. dev.bge.0.forced_collapse) instead > > > > > of hw.bge.forced_collapse which may affect all bge(4) controllers > > > > > on system. Attached patch may be what you want. You can change the > > > > > value at any time. > > > > > > > > Thank you for the patch. Can it be installed on 8-STABLE ? > > > > > > > > > > bge(4) in HEAD has many fixes which were not MFCed to stable/8 so > > > I'm not sure that patch could be applied cleanly. But I guess you > > > can manually patch it. > > > I'll wait a couple of days for wider testing/review and commit the > > > patch. > > > > Sorry for the late response. We've tested bge.forced_collapse in December > > on HEAD and found that values >1 froze connections with big data amount, > > for example, "top -Ss1" output. Connection with small data amount such as > > short ssh commands worked OK. Now I've tested modern 7.2-STABLE and found > > that forced_collapse >1 freezes it too. > > > > Thanks for reporting! It seems I've incorrectly dropped mbuf chains > when collapsing fails. Would you try attached patch? Thank you, the patch fixes the bug. > Index: sys/dev/bge/if_bge.c > =================================================================== > --- sys/dev/bge/if_bge.c (revision 202268) > +++ sys/dev/bge/if_bge.c (working copy) > @@ -3940,11 +3940,8 @@ > m = m_defrag(m, M_DONTWAIT); > else > m = m_collapse(m, M_DONTWAIT, sc->bge_forced_collapse); > - if (m == NULL) { > - m_freem(*m_head); > - *m_head = NULL; > - return (ENOBUFS); > - } > + if (m == NULL) > + m = *m_head; > *m_head = m; > } > -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Fri Jan 15 10:25:28 2010 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 9D742106568B for ; Fri, 15 Jan 2010 10:25:28 +0000 (UTC) (envelope-from sh@keff.org) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id 3DFB38FC0A for ; Fri, 15 Jan 2010 10:25:27 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id d26so34524eyd.9 for ; Fri, 15 Jan 2010 02:25:21 -0800 (PST) Received: by 10.213.47.16 with SMTP id l16mr715914ebf.7.1263551121467; Fri, 15 Jan 2010 02:25:21 -0800 (PST) Received: from ?10.156.17.105? (workstation1.tele2.se [192.71.219.1]) by mx.google.com with ESMTPS id 10sm211559eyd.21.2010.01.15.02.25.20 (version=SSLv3 cipher=RC4-MD5); Fri, 15 Jan 2010 02:25:20 -0800 (PST) Message-ID: <4B504290.5020506@keff.org> Date: Fri, 15 Jan 2010 11:25:20 +0100 From: Sebastian Hyrwall 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 Subject: FreeBSD 7.2 vs Linux in routing 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: Fri, 15 Jan 2010 10:25:28 -0000 Hi I have to identical x86 routers with the following specifications, hw.model: Intel(R) Atom(TM) CPU 330 @ 1.60GHz hw.physmem: 2132996096 hw.usermem: 1787252736 hw.realmem: 2146041856 2x re0: port 0xd800-0xd8ff mem 0xfeaff000-0xfeafffff,0xfdef0000-0xfdefffff irq 16 at device 0.0 on pci2 I know it's not really the best equipment to use in gbit-enviroments but that is irrelevant here. One of these runs FreeBSD 7.2 (R-p4) and the other Linux 2.6.31.5. Without pf/iptables loaded the FreeBSD-server maxes out at 35MB/s when it comes to forwarding between the two NICs (simple http-transfer used for testing). The Linux-server pushes 90-100MB/s between the NICs with the same test. Both servers are connected the same way to the network (I swap them between the testing). Any suggestions on where the gigantic performance loss might be and how to fix it? I intend to switch FreeBSD 8 in the coming month and maybe that will fix the problem but I am hoping it's also fixable in 7.2. Sincerely, Sebastian H. From owner-freebsd-net@FreeBSD.ORG Fri Jan 15 12:49:44 2010 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 D82BB1065672 for ; Fri, 15 Jan 2010 12:49:44 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from mailrelay1.rambler.ru (mailrelay1.rambler.ru [81.19.66.239]) by mx1.freebsd.org (Postfix) with ESMTP id 4F1668FC1E for ; Fri, 15 Jan 2010 12:49:43 +0000 (UTC) Received: from kas30pipe.localhost (localhost [127.0.0.1]) by mailrelay1.rambler.ru (Postfix) with ESMTP id D0C96130C64; Fri, 15 Jan 2010 15:49:42 +0300 (MSK) Received: from localhost (sysoev.ru [81.19.68.137]) by mailrelay1.rambler.ru (Postfix) with ESMTP id 334E8130C44; Fri, 15 Jan 2010 15:49:42 +0300 (MSK) Date: Fri, 15 Jan 2010 15:49:42 +0300 From: Igor Sysoev To: Pyun YongHyeon Message-ID: <20100115124942.GN84494@rambler-co.ru> References: <20091204075440.GH14822@rambler-co.ru> <20091204173243.GC16491@michelle.cdnetworks.com> <20091204191114.GB76992@rambler-co.ru> <20091204195140.GH16491@michelle.cdnetworks.com> <20091204201303.GD76992@rambler-co.ru> <20091204202213.GI16491@michelle.cdnetworks.com> <20100114160333.GC16657@rambler-co.ru> <20100114181031.GX1228@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20100114181031.GX1228@michelle.cdnetworks.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Anti-Virus: Kaspersky Anti-Virus for MailServers 5.5.33/RELEASE, bases: 02092009 #2738642, status: clean X-SpamTest-Envelope-From: is@rambler-co.ru X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 9536 [Sen 02 2009] X-SpamTest-Info: {HEADERS: header Content-Type found without required header Content-Transfer-Encoding} X-SpamTest-Method: none X-SpamTest-Rate: 10 X-SpamTest-SPF: pass X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release Cc: freebsd-net@freebsd.org Subject: Re: hw.bge.forced_collapse 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, 15 Jan 2010 12:49:45 -0000 On Thu, Jan 14, 2010 at 10:10:31AM -0800, Pyun YongHyeon wrote: > On Thu, Jan 14, 2010 at 07:03:33PM +0300, Igor Sysoev wrote: > > On Fri, Dec 04, 2009 at 12:22:13PM -0800, Pyun YongHyeon wrote: > > > > > On Fri, Dec 04, 2009 at 11:13:03PM +0300, Igor Sysoev wrote: > > > > On Fri, Dec 04, 2009 at 11:51:40AM -0800, Pyun YongHyeon wrote: > > > > > > > > > On Fri, Dec 04, 2009 at 10:11:14PM +0300, Igor Sysoev wrote: > > > > > > On Fri, Dec 04, 2009 at 09:32:43AM -0800, Pyun YongHyeon wrote: > > > > > > > > > > > > > On Fri, Dec 04, 2009 at 10:54:40AM +0300, Igor Sysoev wrote: > > > > > > > > I saw commit introducing hw.bge.forced_collapse loader tunable. > > > > > > > > Just intresting, why it can not be a sysctl ? > > > > > > > > > > > > > > I didn't think the sysctl variable would be frequently changed > > > > > > > in runtime except debugging driver so I took simple path. > > > > > > > > > > > > I do not think it's worth to reboot server just to look how various > > > > > > values affect on bandwidth and CPU usage, expecially in production. > > > > > > > > > > > > As I understand the change is trivial: > > > > > > > > > > > > - CTLFLAG_RD > > > > > > + CTLFLAG_RW > > > > > > > > > > > > since bge_forced_collapse is used atomically. > > > > > > > > > > > > > > > > I have no problem changing it to RW but that case I may have to > > > > > create actual sysctl node(e.g. dev.bge.0.forced_collapse) instead > > > > > of hw.bge.forced_collapse which may affect all bge(4) controllers > > > > > on system. Attached patch may be what you want. You can change the > > > > > value at any time. > > > > > > > > Thank you for the patch. Can it be installed on 8-STABLE ? > > > > > > > > > > bge(4) in HEAD has many fixes which were not MFCed to stable/8 so > > > I'm not sure that patch could be applied cleanly. But I guess you > > > can manually patch it. > > > I'll wait a couple of days for wider testing/review and commit the > > > patch. > > > > Sorry for the late response. We've tested bge.forced_collapse in December > > on HEAD and found that values >1 froze connections with big data amount, > > for example, "top -Ss1" output. Connection with small data amount such as > > short ssh commands worked OK. Now I've tested modern 7.2-STABLE and found > > that forced_collapse >1 freezes it too. > > > > Thanks for reporting! It seems I've incorrectly dropped mbuf chains > when collapsing fails. Would you try attached patch? BTW, it's strange that collapsing fails too often. > Index: sys/dev/bge/if_bge.c > =================================================================== > --- sys/dev/bge/if_bge.c (revision 202268) > +++ sys/dev/bge/if_bge.c (working copy) > @@ -3940,11 +3940,8 @@ > m = m_defrag(m, M_DONTWAIT); > else > m = m_collapse(m, M_DONTWAIT, sc->bge_forced_collapse); > - if (m == NULL) { > - m_freem(*m_head); > - *m_head = NULL; > - return (ENOBUFS); > - } > + if (m == NULL) > + m = *m_head; > *m_head = m; > } > -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Fri Jan 15 17:22:01 2010 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 346831065670 for ; Fri, 15 Jan 2010 17:22:01 +0000 (UTC) (envelope-from erik@malcolm.berkeley.edu) Received: from malcolm.berkeley.edu (malcolm.Berkeley.EDU [IPv6:2607:f140:ffff:ffff::239]) by mx1.freebsd.org (Postfix) with ESMTP id 123A88FC08 for ; Fri, 15 Jan 2010 17:22:01 +0000 (UTC) Received: from malcolm.berkeley.edu (localhost [127.0.0.1]) by malcolm.berkeley.edu (8.14.3/8.13.8m1) with ESMTP id o0FHM0JU040890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 15 Jan 2010 09:22:00 -0800 (PST) (envelope-from erik@malcolm.berkeley.edu) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at malcolm.berkeley.edu Received: (from erik@localhost) by malcolm.berkeley.edu (8.14.3/8.13.3/Submit) id o0FHM05u040876 for freebsd-net@freebsd.org; Fri, 15 Jan 2010 09:22:00 -0800 (PST) (envelope-from erik) Date: Fri, 15 Jan 2010 09:22:00 -0800 From: Erik Klavon To: freebsd-net@freebsd.org Message-ID: <20100115172200.GA40842@malcolm.berkeley.edu> References: <20100114224635.GA27139@malcolm.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100114224635.GA27139@malcolm.berkeley.edu> User-Agent: Mutt/1.4.2.3i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (malcolm.berkeley.edu [127.0.0.1]); Fri, 15 Jan 2010 09:22:00 -0800 (PST) Subject: Re: netgraph mkpeer and connect failures with ng_ipfw and ng_nat 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, 15 Jan 2010 17:22:01 -0000 On Thu, Jan 14, 2010 at 02:46:35PM -0800, Erik Klavon wrote: > I have several dual processor, single core amd64 machines running > 8.0p1. These machines use netgraph to implement one to one NAT with > one ng_nat(4) node for each network client behind them. ipfw(8) rules > direct traffic to netgraph nodes as needed based on table entries > using an ng_ipfw(4) node. As clients join and leave the network, > scripts dynamically create and delete NAT sessions by making calls to > ipfw(8), ngctl(8) and arp(8) to create and delete ng_nat(4) nodes, > ipfw(8) table and published ARP entries. This scheme has worked well > so far in all places we're using it except one. > > In the problematic case, immediately following boot up, creation and > deletion of sessions work consistently. After a couple of hours, long > enough for roughly 100 session creations and deletions, creation and > deletion of sessions will occasionally fail during calls to > ngctl(8). In all other cases, creation and deletion of sessions work > consistently. The rate of session change appears to be greater in the > problematic case, though the total number of active sessions when > session creation and deletion start to fail is below the total number > of sessions we see in non problematic cases. I have swapped out the > machine in the problematic case with another machine with an identical > configuration. This did not result in a change in behavior. > > Here are the calls to ngctl(8) we use to create a one to one NAT > session, with the first two octets in the globally routable IPv4 > addresses replaced with an "x". > > ngctl mkpeer ipfw: nat 202182094 out > ngctl name ipfw:202182094 WirelessNAT2182094 > ngctl connect ipfw: WirelessNAT2182094: 102182094 in > ngctl msg WirelessNAT2182094: setaliasaddr x.x.182.94 > ngctl msg WirelessNAT2182094: redirectaddr \ > '{'"local_addr=10.10.115.242" "alias_addr=x.x.182.94" \ > 'description="Static NAT"' '}' > > For the identifiers above, we represent the globally routable IPv4 > address by an integer such as 2182094. The first digit of this integer > represents the first two octets in the address (all addresses used > have the same first two octets). The remaining digits are the third > and forth octets with padded leading zeros as needed. We generate the > hook names by prepending a two digit int representing the direction > (20 out, 10 in) to the integer representing the globally routable IPv4 > address. This guarantees unique identifiers for all hooks and ng_nat(4) > node names. We use multiple checks in the script that calls ngctl(8) to > ensure that each globally routable address is used in exactly one > session. We use a lock around the above calls prevent two session > creation attempts from interleaving their ngctl(8) calls. > > Here is the call to ngctl(8) we use to delete a one to one NAT > session. The lock around this call is the same used for creating a > session. > > ngctl shutdown ipfw:202182094 > > The first error leading to a session creation or deletion failure > after booting I've observed is in the mkpeer call. Here is an example > from yesterday, after booting the machine at roughly 0500. > > Jan 13 08:44:42 nac[11721]: ngctl: send msg: File exists > Jan 13 08:44:42 nac[11722]: warning: Unsuccessful execution: /usr/sbin/ngctl mkpeer ipfw: nat 202182094 out > > This mkpeer call is the first time since boot that the globally > routable IP address x.x.182.94 was used and the first attempt to > create a hook named 202182094. Output from vmstat(8) -z captured every > minute shows no incrementing of the allocation failure > counters from well before 0844 to 0848. Reducing the number of > netgraph threads (from 2 to 1) via the sysctl net.graph.threads has > not had an effect on this problem. I can not think of any obvious > reasons why this mkpeer call might have failed. 102 mkpeer calls prior > to it did not. > > When a mkpeer call succeeds, the subsequent connect call in the above > session creation sequence will fail, also with a "File exists" > error. The next failure after the above example from yesterday is an > example of this problem. > > Jan 13 08:51:45 nac[51209]: ngctl: send msg: File exists > Jan 13 08:51:45 nac[51212]: warning: Unsuccessful execution: /usr/sbin/ngctl connect ipfw: WirelessNAT2175205: 102175205 in > > Also in this case, this is the first time since boot that the globally > routable IP address x.x.175.205 was used and the first attempt to > create a hook named 102175205. Output from vmstat(8) -z captured every > minute shows no incrementing of the allocation failure > counters from 0849 to 0900. There is an increment of the allocation > failure counter for the 128 Bucket in vmstat(8) -z between 0848 and 0849; > I assume that this is too far away in time from the two above events > to be related. Also, the "File exists" error results from a check > I don't think is related to memory allocation (see below). > > This morning prior to a reboot I modified the ngctl(8) calls to include > the -d flag and obtained the following additional information. > > Jan 14 08:35:08 nac[3234]: ngctl: sendto(ipfw:): File exists > Jan 14 08:35:08 nac[3234]: ngctl: send msg: File exists > Jan 14 08:35:08 nac[3235]: warning: Unsuccessful execution: /usr/sbin/ngctl -d mkpeer ipfw: nat 202183148 out > > Jan 14 08:47:50 nac[94270]: ngctl: sendto(ipfw:): File exists > Jan 14 08:47:50 nac[94270]: ngctl: send msg: File exists > Jan 14 08:47:50 nac[94271]: warning: Unsuccessful execution: /usr/sbin/ngctl -d connect ipfw: WirelessNAT2175111: 102175111 in > > This points to ng_ipfw(4) as the source of these errors. I took a very > quick look at the code to come up with the following interpretations; > please let me know if you see any mistakes in the following. It looks > to me like the error string "File exists" is displayed by ngctl(8) when > the EEXIST constant is returned from ng_ipfw(4) when processing the > command issued via ngctl(8). There is one place in ng_ipfw(4) where EEXIST > is returned. This section of code appears to be used only when the > single ipfw(8) node is first created, so I don't think it should be the > source of the problem in this case. This leaves the parts of ng_base > used to handle generic operations. EEXIST is returned by ng_base.c in > the following functions. > > ng_newtype (called when a new netgraph type is installed) > ng_add_hook (add an unconnected hook to a node) > ng_con_nodes (connect this node with another node) > ng_con_part2 (make the connection in the opposite direction of ng_con_nodes) > > ng_newtype probably isn't the source of the problem in this case, > since we're not working with a new type. The other three functions are > possible candidates for each of the above two error examples as in > both cases hooks are created and connected. Here are the conditional > statements that check for an EEXIST condition. > > ng_add_hook if (ng_findhook(node, name) != NULL) { > ng_con_nodes if (ng_findhook(node2, name2) != NULL) { > ng_con_part2 if (ng_findhook(node, NG_HOOK_NAME(hook)) != NULL) { > > In each of these cases, it appears that the code is checking to see if > a hook with the argument name exists before creating a hook with that > name. Given the conditions in the above two example errors that the > hook names are unique and no hooks with these same names were > previously created, I can't explain why the above calls to ng_findhook > are returning references to hooks. Each ng_ipfw(4) hook has associated with it a u_int16_t variable rulenum as part of the ng_ipfw_hook_priv struct. When a hook is created, in ng_ipfw_newhook rulenum is set to a value obtained from the hook name via the following conversion. /* Convert it to integer */ rulenum = (u_int16_t)strtol(name, &endptr, 10); ng_ipfw(4)'s implementation of ng_findhook, ng_ipfw_findhook, uses this conversion to supply a u_int16_t to ng_ipfw_findhook1, which performs a direct binary comparison between the argument value and the rulenum associated with each hook in place of the call to strcmp in ng_ipfw's implementation of ng_findhook. I used the following program with data taken from one of the examples in my last followup to Julian (which I duplicate at the end of this message) to test this logic. #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include int main() { int tablesize = 118; int i = 0; char *table[tablesize]; char *name, *endptr; u_int16_t n, t; table[0] = "102175162"; table[1] = "202175162"; table[2] = "102182226"; table[3] = "202182226"; table[4] = "102182009"; table[5] = "202182009"; table[6] = "202174135"; table[7] = "102173144"; table[8] = "202173144"; table[9] = "102183171"; table[10] = "202183171"; table[11] = "102172040"; table[12] = "202172040"; table[13] = "102173235"; table[14] = "202173235"; table[15] = "102174107"; table[16] = "202174107"; table[17] = "102173033"; table[18] = "202173033"; table[19] = "102183226"; table[20] = "202183226"; table[21] = "102172216"; table[22] = "202172216"; table[23] = "102182129"; table[24] = "202182129"; table[25] = "102173201"; table[26] = "202173201"; table[27] = "102132178"; table[28] = "202132178"; table[29] = "102183212"; table[30] = "202183212"; table[31] = "102173179"; table[32] = "202173179"; table[33] = "102172132"; table[34] = "202172132"; table[35] = "102175045"; table[36] = "202175045"; table[37] = "102175215"; table[38] = "202175215"; table[39] = "102183173"; table[40] = "202183173"; table[41] = "102173180"; table[42] = "202173180"; table[43] = "102173171"; table[44] = "202173171"; table[45] = "102173025"; table[46] = "202173025"; table[47] = "102175064"; table[48] = "202175064"; table[49] = "102172038"; table[50] = "202172038"; table[51] = "102175035"; table[52] = "202175035"; table[53] = "102182254"; table[54] = "202182254"; table[55] = "102183083"; table[56] = "202183083"; table[57] = "102132088"; table[58] = "202132088"; table[59] = "102183201"; table[60] = "202183201"; table[61] = "102182255"; table[62] = "202182255"; table[63] = "102172085"; table[64] = "202172085"; table[65] = "102183127"; table[66] = "202183127"; table[67] = "102173146"; table[68] = "202173146"; table[69] = "102182071"; table[70] = "202182071"; table[71] = "102172073"; table[72] = "202172073"; table[73] = "102173186"; table[74] = "202173186"; table[75] = "102175067"; table[76] = "202175067"; table[77] = "102173061"; table[78] = "202173061"; table[79] = "102183115"; table[80] = "202183115"; table[81] = "102132147"; table[82] = "202132147"; table[83] = "102182233"; table[84] = "202182233"; table[85] = "102183051"; table[86] = "202183051"; table[87] = "102183102"; table[88] = "202183102"; table[89] = "102172157"; table[90] = "202172157"; table[91] = "102174083"; table[92] = "202174083"; table[93] = "102132017"; table[94] = "202132017"; table[95] = "102172065"; table[96] = "202172065"; table[97] = "102132142"; table[98] = "202132142"; table[99] = "102183163"; table[100] = "202183163"; table[101] = "102173094"; table[102] = "202173094"; table[103] = "102172147"; table[104] = "202172147"; table[105] = "102173066"; table[106] = "202173066"; table[107] = "102132098"; table[108] = "202132098"; table[109] = "102173166"; table[110] = "202173166"; table[111] = "102132096"; table[112] = "202132096"; table[113] = "102183229"; table[114] = "202183229"; table[115] = "102173220"; table[116] = "202173220"; table[117] = "1"; table[118] = "2"; name = "102174135"; n = (u_int16_t)strtol(name, &endptr, 10); for (i = 0; i <= tablesize; i++) { t = (u_int16_t)strtol(table[i], &endptr, 10); if (n == t) { printf("%s matches %s\n", name, table[i]); } } } saving this as test.c in sys/netgraph/, compiling and running it on the machine that produced the data under test via the following commands I get the following output. sudo gcc test.c -o test ./test 102174135 matches 202182071 Based on this result, I am able to reproduce the problem on a test system as follows: sudo ngctl list There are 3 total nodes: Name: UnauthNat Type: nat ID: 00000004 Num hooks: 2 Name: ipfw Type: ipfw ID: 00000001 Num hooks: 2 Name: ngctl2605 Type: socket ID: 00000008 Num hooks: 0 sudo ngctl -d mkpeer ipfw: nat 202182071 out sudo ngctl -d mkpeer ipfw: nat 102174135 out ngctl: sendto(ipfw:): File exists ngctl: send msg: File exists sudo ngctl list There are 4 total nodes: Name: Type: nat ID: 0000000a Num hooks: 1 Name: UnauthNat Type: nat ID: 00000004 Num hooks: 2 Name: ipfw Type: ipfw ID: 00000001 Num hooks: 3 Name: ngctl2612 Type: socket ID: 0000000d Num hooks: 0 The use of a u_int16_t representation of the hook name is limited to ng_ipfw_findhook1. ng_ipfw_findhook1 is called directly from ng_ipfw_findhook and also ng_ipfw_input where it takes its u_int16_t argument from the cookie field of the tag associated with the packet (an ip_fw_args struct). This field, as defined in sys/netinet/ip_fw.h, has type uint32_t. So this problem easily fixed by using a u_int32_t instead of a u_int16_t. Here is a patch. --- ng_ipfw.c.orig 2010-01-15 08:20:37.000000000 -0800 +++ ng_ipfw.c 2010-01-15 08:21:49.000000000 -0800 @@ -61,7 +61,7 @@ static ng_rcvdata_t ng_ipfw_rcvdata; static ng_disconnect_t ng_ipfw_disconnect; -static hook_p ng_ipfw_findhook1(node_p, u_int16_t ); +static hook_p ng_ipfw_findhook1(node_p, u_int32_t ); static int ng_ipfw_input(struct mbuf **, int, struct ip_fw_args *, int); @@ -87,7 +87,7 @@ /* Information we store for each hook */ struct ng_ipfw_hook_priv { hook_p hook; - u_int16_t rulenum; + u_int32_t rulenum; }; typedef struct ng_ipfw_hook_priv *hpriv_p; @@ -145,7 +145,7 @@ ng_ipfw_newhook(node_p node, hook_p hook, const char *name) { hpriv_p hpriv; - u_int16_t rulenum; + u_int32_t rulenum; const char *cp; char *endptr; @@ -159,7 +159,7 @@ return (EINVAL); /* Convert it to integer */ - rulenum = (u_int16_t)strtol(name, &endptr, 10); + rulenum = (u_int32_t)strtol(name, &endptr, 10); if (*endptr != '\0') return (EINVAL); @@ -191,10 +191,10 @@ hook_p ng_ipfw_findhook(node_p node, const char *name) { - u_int16_t n; /* numeric representation of hook */ + u_int32_t n; /* numeric representation of hook */ char *endptr; - n = (u_int16_t)strtol(name, &endptr, 10); + n = (u_int32_t)strtol(name, &endptr, 10); if (*endptr != '\0') return NULL; return ng_ipfw_findhook1(node, n); @@ -202,7 +202,7 @@ /* Look up hook by rule number */ static hook_p -ng_ipfw_findhook1(node_p node, u_int16_t rulenum) +ng_ipfw_findhook1(node_p node, u_int32_t rulenum) { hook_p hook; hpriv_p hpriv; After applying this patch and rebooting with the new ng_ipfw(4) kernel module, I am no longer able to reproduce the problem. sudo ngctl list There are 3 total nodes: Name: UnauthNat Type: nat ID: 00000004 Num hooks: 2 Name: ipfw Type: ipfw ID: 00000001 Num hooks: 2 Name: ngctl2600 Type: socket ID: 00000008 Num hooks: 0 sudo ngctl -d mkpeer ipfw: nat 202182071 out sudo ngctl -d mkpeer ipfw: nat 102174135 out sudo ngctl list There are 5 total nodes: Name: Type: nat ID: 0000000c Num hooks: 1 Name: Type: nat ID: 0000000a Num hooks: 1 Name: UnauthNat Type: nat ID: 00000004 Num hooks: 2 Name: ipfw Type: ipfw ID: 00000001 Num hooks: 4 Name: ngctl2607 Type: socket ID: 0000000d Num hooks: 0 I will install the patched ng_ipfw(4) kernel module on the machine where I first noticed these problems tomorrow to see if it works in production. Here is the failure I used as my test case. I took the hook name 102174135 from the error message and populated the table with the values in the Local hook column from the output of ngctl show ipfw. Jan 14 08:28:08 nac[70382]: /usr/sbin/ngctl -d mkpeer ipfw: nat 202174135 out Jan 14 08:28:08 nac[70388]: /usr/sbin/ngctl -d name ipfw:202174135 WirelessNAT2174135 Jan 14 08:28:08 nac[70394]: /usr/sbin/ngctl -d connect ipfw: WirelessNAT2174135: 102174135 in Jan 14 08:28:08 nac[70399]: ngctl: sendto(ipfw:): File exists Jan 14 08:28:08 nac[70399]: ngctl: send msg: File exists Thu Jan 14 08:29:01 PST 2010 /usr/sbin/ngctl show ipfw: Name: ipfw Type: ipfw ID: 00000001 Num hooks: 119 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- 102175162 WirelessNAT2175162 nat 00000315 in 202175162 WirelessNAT2175162 nat 00000315 out 102182226 WirelessNAT2182226 nat 0000030f in 202182226 WirelessNAT2182226 nat 0000030f out 102182009 WirelessNAT2182009 nat 00000309 in 202182009 WirelessNAT2182009 nat 00000309 out 202174135 WirelessNAT2174135 nat 00000305 out 102173144 WirelessNAT2173144 nat 000002fd in 202173144 WirelessNAT2173144 nat 000002fd out 102183171 WirelessNAT2183171 nat 000002f7 in 202183171 WirelessNAT2183171 nat 000002f7 out 102172040 WirelessNAT2172040 nat 000002ef in 202172040 WirelessNAT2172040 nat 000002ef out 102173235 WirelessNAT2173235 nat 000002e9 in 202173235 WirelessNAT2173235 nat 000002e9 out 102174107 WirelessNAT2174107 nat 000002e3 in 202174107 WirelessNAT2174107 nat 000002e3 out 102173033 WirelessNAT2173033 nat 000002db in 202173033 WirelessNAT2173033 nat 000002db out 102183226 WirelessNAT2183226 nat 000002d5 in 202183226 WirelessNAT2183226 nat 000002d5 out 102172216 WirelessNAT2172216 nat 000002cf in 202172216 WirelessNAT2172216 nat 000002cf out 102182129 WirelessNAT2182129 nat 000002c8 in 202182129 WirelessNAT2182129 nat 000002c8 out 102173201 WirelessNAT2173201 nat 000002c0 in 202173201 WirelessNAT2173201 nat 000002c0 out 102132178 WirelessNAT2132178 nat 000002b8 in 202132178 WirelessNAT2132178 nat 000002b8 out 102183212 WirelessNAT2183212 nat 000002b0 in 202183212 WirelessNAT2183212 nat 000002b0 out 102173179 WirelessNAT2173179 nat 000002a8 in 202173179 WirelessNAT2173179 nat 000002a8 out 102172132 WirelessNAT2172132 nat 0000029f in 202172132 WirelessNAT2172132 nat 0000029f out 102175045 WirelessNAT2175045 nat 00000297 in 202175045 WirelessNAT2175045 nat 00000297 out 102175215 WirelessNAT2175215 nat 0000028f in 202175215 WirelessNAT2175215 nat 0000028f out 102183173 WirelessNAT2183173 nat 00000287 in 202183173 WirelessNAT2183173 nat 00000287 out 102173180 WirelessNAT2173180 nat 0000027f in 202173180 WirelessNAT2173180 nat 0000027f out 102173171 WirelessNAT2173171 nat 00000279 in 202173171 WirelessNAT2173171 nat 00000279 out 102173025 WirelessNAT2173025 nat 00000271 in 202173025 WirelessNAT2173025 nat 00000271 out 102175064 WirelessNAT2175064 nat 00000269 in 202175064 WirelessNAT2175064 nat 00000269 out 102172038 WirelessNAT2172038 nat 00000263 in 202172038 WirelessNAT2172038 nat 00000263 out 102175035 WirelessNAT2175035 nat 0000025b in 202175035 WirelessNAT2175035 nat 0000025b out 102182254 WirelessNAT2182254 nat 00000255 in 202182254 WirelessNAT2182254 nat 00000255 out 102183083 WirelessNAT2183083 nat 0000024f in 202183083 WirelessNAT2183083 nat 0000024f out 102132088 WirelessNAT2132088 nat 00000245 in 202132088 WirelessNAT2132088 nat 00000245 out 102183201 WirelessNAT2183201 nat 0000023f in 202183201 WirelessNAT2183201 nat 0000023f out 102182255 WirelessNAT2182255 nat 00000237 in 202182255 WirelessNAT2182255 nat 00000237 out 102172085 WirelessNAT2172085 nat 00000231 in 202172085 WirelessNAT2172085 nat 00000231 out 102183127 WirelessNAT2183127 nat 00000228 in 202183127 WirelessNAT2183127 nat 00000228 out 102173146 WirelessNAT2173146 nat 0000021c in 202173146 WirelessNAT2173146 nat 0000021c out 102182071 WirelessNAT2182071 nat 0000020e in 202182071 WirelessNAT2182071 nat 0000020e out 102172073 WirelessNAT2172073 nat 00000208 in 202172073 WirelessNAT2172073 nat 00000208 out 102173186 WirelessNAT2173186 nat 00000200 in 202173186 WirelessNAT2173186 nat 00000200 out 102175067 WirelessNAT2175067 nat 000001f8 in 202175067 WirelessNAT2175067 nat 000001f8 out 102173061 WirelessNAT2173061 nat 000001f2 in 202173061 WirelessNAT2173061 nat 000001f2 out 102183115 WirelessNAT2183115 nat 000001ec in 202183115 WirelessNAT2183115 nat 000001ec out 102132147 WirelessNAT2132147 nat 000001e6 in 202132147 WirelessNAT2132147 nat 000001e6 out 102182233 WirelessNAT2182233 nat 000001d8 in 202182233 WirelessNAT2182233 nat 000001d8 out 102183051 WirelessNAT2183051 nat 000001d0 in 202183051 WirelessNAT2183051 nat 000001d0 out 102183102 WirelessNAT2183102 nat 000001c6 in 202183102 WirelessNAT2183102 nat 000001c6 out 102172157 WirelessNAT2172157 nat 000001c0 in 202172157 WirelessNAT2172157 nat 000001c0 out 102174083 WirelessNAT2174083 nat 000001ba in 202174083 WirelessNAT2174083 nat 000001ba out 102132017 WirelessNAT2132017 nat 000001b2 in 202132017 WirelessNAT2132017 nat 000001b2 out 102172065 WirelessNAT2172065 nat 000001a8 in 202172065 WirelessNAT2172065 nat 000001a8 out 102132142 WirelessNAT2132142 nat 0000019e in 202132142 WirelessNAT2132142 nat 0000019e out 102183163 WirelessNAT2183163 nat 00000198 in 202183163 WirelessNAT2183163 nat 00000198 out 102173094 WirelessNAT2173094 nat 00000190 in 202173094 WirelessNAT2173094 nat 00000190 out 102172147 WirelessNAT2172147 nat 00000188 in 202172147 WirelessNAT2172147 nat 00000188 out 102173066 WirelessNAT2173066 nat 00000174 in 202173066 WirelessNAT2173066 nat 00000174 out 102132098 WirelessNAT2132098 nat 0000016c in 202132098 WirelessNAT2132098 nat 0000016c out 102173166 WirelessNAT2173166 nat 00000154 in 202173166 WirelessNAT2173166 nat 00000154 out 102132096 WirelessNAT2132096 nat 00000134 in 202132096 WirelessNAT2132096 nat 00000134 out 102183229 WirelessNAT2183229 nat 00000126 in 202183229 WirelessNAT2183229 nat 00000126 out 102173220 WirelessNAT2173220 nat 00000010 in 202173220 WirelessNAT2173220 nat 00000010 out 1 UnauthNat nat 00000004 in 2 UnauthNat nat 00000004 out Erik From owner-freebsd-net@FreeBSD.ORG Fri Jan 15 18:04:16 2010 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 3D97D106568F for ; Fri, 15 Jan 2010 18:04:16 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id D14CC8FC0C for ; Fri, 15 Jan 2010 18:04:15 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so101938qwd.7 for ; Fri, 15 Jan 2010 10:04:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=o69uMZN5w3GJUoLAAOiFBUY9/aQWvxpw7Y0DPDWjXDY=; b=mwjEptXUGV3v4webfIRmtBVhxPGQA5gkdxLJBdbrRQdJ2T7uJLPpJLmb+OMlT5C+F6 hrPXFI4MYRVQGpbzzHLZNdEX3DOJuiL0JdliGWX1NHaG0psPLHuxBFXPI/QzGxygWhXY pvuMNIPi6T+qArs7tYLA5IUMkhZojBk5NAFe8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=EKThkHY5vzciPmKDUKR2iQ7nNpaGADccV/kvx8ZzR2fSJ6ki8AKzpI+YVOh/ccS5dT U8KU7+YRVWgRr7qR9oqvgBO97rmyb5MR0qLPhgGTRIfYO+p8gbOGvlUndJpOM6XV9dOW rDGx8byvfelRTT9iUCWWnuX/rRXadP50wxc9o= Received: by 10.224.15.206 with SMTP id l14mr2427879qaa.117.1263578649418; Fri, 15 Jan 2010 10:04:09 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 7sm5415937qwf.34.2010.01.15.10.04.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 15 Jan 2010 10:04:07 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 15 Jan 2010 10:03:26 -0800 From: Pyun YongHyeon Date: Fri, 15 Jan 2010 10:03:26 -0800 To: Igor Sysoev Message-ID: <20100115180326.GF1228@michelle.cdnetworks.com> References: <20091204075440.GH14822@rambler-co.ru> <20091204173243.GC16491@michelle.cdnetworks.com> <20091204191114.GB76992@rambler-co.ru> <20091204195140.GH16491@michelle.cdnetworks.com> <20091204201303.GD76992@rambler-co.ru> <20091204202213.GI16491@michelle.cdnetworks.com> <20100114160333.GC16657@rambler-co.ru> <20100114181031.GX1228@michelle.cdnetworks.com> <20100115124942.GN84494@rambler-co.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100115124942.GN84494@rambler-co.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: hw.bge.forced_collapse X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 18:04:16 -0000 On Fri, Jan 15, 2010 at 03:49:42PM +0300, Igor Sysoev wrote: > On Thu, Jan 14, 2010 at 10:10:31AM -0800, Pyun YongHyeon wrote: > > > On Thu, Jan 14, 2010 at 07:03:33PM +0300, Igor Sysoev wrote: > > > On Fri, Dec 04, 2009 at 12:22:13PM -0800, Pyun YongHyeon wrote: > > > > > > > On Fri, Dec 04, 2009 at 11:13:03PM +0300, Igor Sysoev wrote: > > > > > On Fri, Dec 04, 2009 at 11:51:40AM -0800, Pyun YongHyeon wrote: > > > > > > > > > > > On Fri, Dec 04, 2009 at 10:11:14PM +0300, Igor Sysoev wrote: > > > > > > > On Fri, Dec 04, 2009 at 09:32:43AM -0800, Pyun YongHyeon wrote: > > > > > > > > > > > > > > > On Fri, Dec 04, 2009 at 10:54:40AM +0300, Igor Sysoev wrote: > > > > > > > > > I saw commit introducing hw.bge.forced_collapse loader tunable. > > > > > > > > > Just intresting, why it can not be a sysctl ? > > > > > > > > > > > > > > > > I didn't think the sysctl variable would be frequently changed > > > > > > > > in runtime except debugging driver so I took simple path. > > > > > > > > > > > > > > I do not think it's worth to reboot server just to look how various > > > > > > > values affect on bandwidth and CPU usage, expecially in production. > > > > > > > > > > > > > > As I understand the change is trivial: > > > > > > > > > > > > > > - CTLFLAG_RD > > > > > > > + CTLFLAG_RW > > > > > > > > > > > > > > since bge_forced_collapse is used atomically. > > > > > > > > > > > > > > > > > > > I have no problem changing it to RW but that case I may have to > > > > > > create actual sysctl node(e.g. dev.bge.0.forced_collapse) instead > > > > > > of hw.bge.forced_collapse which may affect all bge(4) controllers > > > > > > on system. Attached patch may be what you want. You can change the > > > > > > value at any time. > > > > > > > > > > Thank you for the patch. Can it be installed on 8-STABLE ? > > > > > > > > > > > > > bge(4) in HEAD has many fixes which were not MFCed to stable/8 so > > > > I'm not sure that patch could be applied cleanly. But I guess you > > > > can manually patch it. > > > > I'll wait a couple of days for wider testing/review and commit the > > > > patch. > > > > > > Sorry for the late response. We've tested bge.forced_collapse in December > > > on HEAD and found that values >1 froze connections with big data amount, > > > for example, "top -Ss1" output. Connection with small data amount such as > > > short ssh commands worked OK. Now I've tested modern 7.2-STABLE and found > > > that forced_collapse >1 freezes it too. > > > > > > > Thanks for reporting! It seems I've incorrectly dropped mbuf chains > > when collapsing fails. Would you try attached patch? > > BTW, it's strange that collapsing fails too often. > I think that comes from m_collapse(9) behavior. m_collapse(9) does not want to modify mbuf header pointer of the chain so it has more chance to fail than m_defrag(9) when the number of requested fragment is very low. m_defrag(9) always creates new mbuf so it may have more success rates if you have enough resources. From owner-freebsd-net@FreeBSD.ORG Fri Jan 15 18:55:15 2010 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 74C5A106566C for ; Fri, 15 Jan 2010 18:55:15 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id 2907F8FC12 for ; Fri, 15 Jan 2010 18:55:14 +0000 (UTC) Received: by ywh35 with SMTP id 35so743311ywh.7 for ; Fri, 15 Jan 2010 10:55:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=1UsNEPA19VNpn03qQ8F8p3z9u+hZjbJhGraJbERp04s=; b=QxrWkRusffiB0ar4Q478BHVbVm+Iz8qExqbWC24gz47pmwqL7UVe8IIrJg+gwJjxqu xb8XeknOayOT7dELinsTkzwztL6+Lu8f15tDwJXWa25wW0QNRpKz7LLB42deiHT6Zqh1 bkCKBj8Rp3ErEEfKT8ZkmkMmkjbQmnpbxRtS4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=vuGW5/SzHRyuRK6Nhk1etAviSMryrKFTBd9gaQ2YwaW/Ei6XLCAGAjvETI26lM9ZDz qo3m5qolWnK8AHt5CK1KbOeeImVsljhA9jbzlpNhuCsFhvrjlzHbei5r3UeX6Yq7duV1 p8A4XGN15nCoi3F0md8dDKapDz0vDOZ8A/NFE= Received: by 10.101.139.20 with SMTP id r20mr5146551ann.100.1263581706209; Fri, 15 Jan 2010 10:55:06 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 7sm860275ywc.21.2010.01.15.10.55.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 15 Jan 2010 10:55:05 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 15 Jan 2010 10:54:24 -0800 From: Pyun YongHyeon Date: Fri, 15 Jan 2010 10:54:24 -0800 To: Floris Bos Message-ID: <20100115185424.GG1228@michelle.cdnetworks.com> References: <201001140140.o0E1e5hr072464@freefall.freebsd.org> <201001142148.56444.info@je-eigen-domein.nl> <20100115005316.GB1228@michelle.cdnetworks.com> <201001150333.59107.info@je-eigen-domein.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201001150333.59107.info@je-eigen-domein.nl> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: kern/92090: [bge] bge: watchdog timeout -- resetting X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 18:55:15 -0000 On Fri, Jan 15, 2010 at 03:33:58AM +0100, Floris Bos wrote: > On Friday 15 January 2010 01:53:16 am Pyun YongHyeon wrote: > > On Thu, Jan 14, 2010 at 09:48:56PM +0100, Floris Bos wrote: > > > On Thursday 14 January 2010 09:11:44 pm Pyun YongHyeon wrote: > > > > On Thu, Jan 14, 2010 at 09:08:02PM +0100, Floris Bos wrote: > > > > > On Thursday 14 January 2010 06:56:03 pm Pyun YongHyeon wrote: > > > > > > On Thu, Jan 14, 2010 at 04:33:19AM +0100, Floris Bos wrote: > > > > > > > Hi, > > > > > > > > > > > > > > On Thursday 14 January 2010 03:54:52 am Pyun YongHyeon wrote: > > > > > > > > > == > > > > > > > > > bge0: mem 0xdf900000-0xdf90ffff irq 16 at device 0.0 on pci32 > > > > > > > > > == > > > > > > > > > > > > > > > > > > After boot, the network works for about 5 seconds, barely enough time to get an IP by DHCP, and sent a ping or 2. > > > > > > > > > Then network connectivity goes down, and after some time there is a "bge0: watchdog timeout -- resetting" message. > > > > > > > > > > > > > > > > > > Then network works again for 5 seconds, and goes down again. All the time, repeatedly. > > > > > > > > > > > > > > > > > > The system works fine under Ubuntu. So I assume the hardware is ok. > > > > > > > > > > > > > > > > > > > > > > > > > I'm not sure but it looks like you have a BCM5784 controller. What is > > > > > > > > the output of "devinfo -rv | grep phy"? > > > > > > > > > > > > > > == > > > > > > > ukphy0 pnpinfo oui=0x50ef model=0x3a rev=0x4 at phyno=1 > > > > > > > ukphy1 pnpinfo oui=0x50ef model=0x3a rev=0x4 at phyno=1 > > > > > > > == > > > > > > > > > > > > Support for the PHY was added in r202269. > > > > > > Please try again after applying the change. Or you can download > > > > > > sys/dev/mii/miidevs and sys/dev/mii/brgphy.c from HEAD and rebuild > > > > > > kernel. > > > > > > > > > > Fetched the latest source using CVS on another computer, and transferred it to the system concerned by USB stick. > > > > > Rebuild the kernel, but the problem is still there. > > > > > > > > > Would you show me full dmesg output including "watchodg timeout" > > > > messages? > > > > > > === > > > Copyright (c) 1992-2010 The FreeBSD Project. > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > > The Regents of the University of California. All rights reserved. > > > > [...] > > > > > bge0: mem 0xdf900000-0xdf90ffff irq 16 at device 0.0 on pci32 > > > miibus0: on bge0 > > > brgphy0: PHY 1 on miibus0 > > > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > > > bge0: Ethernet address: f4:ce:46:0f:2a:2c > > > bge0: [FILTER] > > > pcib4: irq 16 at device 28.5 on pci0 > > > pci34: on pcib4 > > > bge1: mem 0xdfa00000-0xdfa0ffff irq 17 at device 0.0 on pci34 > > > miibus1: on bge1 > > > brgphy1: PHY 1 on miibus1 > > > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > > > bge1: Ethernet address: f4:ce:46:0f:2a:2d > > > bge1: [FILTER] > > > > [...] > > > > Would you give attached patch try? I don't know whether it help > > or not though. I couldn't find any related information for possible > > clue of the issue in publicly available datasheet. > > The patch did not make any difference. > > > However I did notice something else odd. > The problem only occurs on bge0, the second interface bge1 does work. > > I grabbed the U57DIAG diagnostic boot CD from the Broadcom site, and noticed that the first interface has ASF enabled, while the second one has not. > I disabled ASF by doing: > > = > b57udiag -cmd > setasf -d > == > > And now the first interface also works properly. > Glad to hear you solved the issue. I totally forgot CURRENT enabled ASF support by default(hw.bge.allow_asf). > So there is something with the ASF stuff that conflicts with FreeBSD. > The IPMI card of the system is configured to use a dedicated 3rd LAN port, and is NOT sharing bge0. > But perhaps the NIC is initialized differently nevertheless when ASF firmware is enabled, and that is causing issues? > Yes, I remember there were a couple of issues related with ASF. Linux seems to have very complex logic to coexist with ASF/IPMI firmware which I don't still understand its implications at this time. bge(4) may need more robust code to handle that but datasheet seems to show very limited information. Lack of ASF/IPMI capable bge(4) controller also make me hard to experiment some code. From owner-freebsd-net@FreeBSD.ORG Fri Jan 15 21:47:14 2010 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 7E661106566C for ; Fri, 15 Jan 2010 21:47:14 +0000 (UTC) (envelope-from info@je-eigen-domein.nl) Received: from mx2.je-eigen-domein.nl (mx2.je-eigen-domein.nl [85.10.196.86]) by mx1.freebsd.org (Postfix) with ESMTP id EBADB8FC0A for ; Fri, 15 Jan 2010 21:47:13 +0000 (UTC) Received: from ubuntu.localnet (localhost [127.0.0.1]) by mx2.je-eigen-domein.nl (Postfix) with ESMTP id A34C9788205; Fri, 15 Jan 2010 22:47:27 +0100 (CET) From: Floris Bos Organization: Maxnet To: pyunyh@gmail.com Date: Fri, 15 Jan 2010 22:46:50 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <201001140140.o0E1e5hr072464@freefall.freebsd.org> <201001150333.59107.info@je-eigen-domein.nl> <20100115185424.GG1228@michelle.cdnetworks.com> In-Reply-To: <20100115185424.GG1228@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_KJOUL+qsQkRfsLe" Message-Id: <201001152246.50315.info@je-eigen-domein.nl> Cc: freebsd-net@freebsd.org Subject: Re: kern/92090: [bge] bge: watchdog timeout -- resetting 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, 15 Jan 2010 21:47:14 -0000 --Boundary-00=_KJOUL+qsQkRfsLe Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit On Friday 15 January 2010 07:54:24 pm Pyun YongHyeon wrote: > On Fri, Jan 15, 2010 at 03:33:58AM +0100, Floris Bos wrote: > > On Friday 15 January 2010 01:53:16 am Pyun YongHyeon wrote: > > > On Thu, Jan 14, 2010 at 09:48:56PM +0100, Floris Bos wrote: > > > > On Thursday 14 January 2010 09:11:44 pm Pyun YongHyeon wrote: > > > > > On Thu, Jan 14, 2010 at 09:08:02PM +0100, Floris Bos wrote: > > > > > > On Thursday 14 January 2010 06:56:03 pm Pyun YongHyeon wrote: > > > > > > > On Thu, Jan 14, 2010 at 04:33:19AM +0100, Floris Bos wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > On Thursday 14 January 2010 03:54:52 am Pyun YongHyeon wrote: > > > > > > > > > > == > > > > > > > > > > bge0: mem 0xdf900000-0xdf90ffff irq 16 at device 0.0 on pci32 > > > > > > > > > > == > > > > > > > > > > > > > > > > > > > > After boot, the network works for about 5 seconds, barely enough time to get an IP by DHCP, and sent a ping or 2. > > > > > > > > > > Then network connectivity goes down, and after some time there is a "bge0: watchdog timeout -- resetting" message. > > > > > > > > > > > > > > > > > > > > Then network works again for 5 seconds, and goes down again. All the time, repeatedly. > > > > > > > > > > > > > > > > > > > > The system works fine under Ubuntu. So I assume the hardware is ok. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm not sure but it looks like you have a BCM5784 controller. What is > > > > > > > > > the output of "devinfo -rv | grep phy"? > > > > > > > > > > > > > > > > == > > > > > > > > ukphy0 pnpinfo oui=0x50ef model=0x3a rev=0x4 at phyno=1 > > > > > > > > ukphy1 pnpinfo oui=0x50ef model=0x3a rev=0x4 at phyno=1 > > > > > > > > == > > > > > > > > > > > > > > Support for the PHY was added in r202269. > > > > > > > Please try again after applying the change. Or you can download > > > > > > > sys/dev/mii/miidevs and sys/dev/mii/brgphy.c from HEAD and rebuild > > > > > > > kernel. > > > > > > > > > > > > Fetched the latest source using CVS on another computer, and transferred it to the system concerned by USB stick. > > > > > > Rebuild the kernel, but the problem is still there. > > > > > > > > > > > Would you show me full dmesg output including "watchodg timeout" > > > > > messages? > > > > > > > > === > > > > Copyright (c) 1992-2010 The FreeBSD Project. > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > > > The Regents of the University of California. All rights reserved. > > > > > > [...] > > > > > > > bge0: mem 0xdf900000-0xdf90ffff irq 16 at device 0.0 on pci32 > > > > miibus0: on bge0 > > > > brgphy0: PHY 1 on miibus0 > > > > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > > > > bge0: Ethernet address: f4:ce:46:0f:2a:2c > > > > bge0: [FILTER] > > > > pcib4: irq 16 at device 28.5 on pci0 > > > > pci34: on pcib4 > > > > bge1: mem 0xdfa00000-0xdfa0ffff irq 17 at device 0.0 on pci34 > > > > miibus1: on bge1 > > > > brgphy1: PHY 1 on miibus1 > > > > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > > > > bge1: Ethernet address: f4:ce:46:0f:2a:2d > > > > bge1: [FILTER] > > > > > > [...] > > > > > > Would you give attached patch try? I don't know whether it help > > > or not though. I couldn't find any related information for possible > > > clue of the issue in publicly available datasheet. > > > > The patch did not make any difference. > > > > > > However I did notice something else odd. > > The problem only occurs on bge0, the second interface bge1 does work. > > > > I grabbed the U57DIAG diagnostic boot CD from the Broadcom site, and noticed that the first interface has ASF enabled, while the second one has not. > > I disabled ASF by doing: > > > > = > > b57udiag -cmd > > setasf -d > > == > > > > And now the first interface also works properly. > > > > Glad to hear you solved the issue. I totally forgot CURRENT enabled > ASF support by default(hw.bge.allow_asf). > > > So there is something with the ASF stuff that conflicts with FreeBSD. > > The IPMI card of the system is configured to use a dedicated 3rd LAN port, and is NOT sharing bge0. > > But perhaps the NIC is initialized differently nevertheless when ASF firmware is enabled, and that is causing issues? > > > > Yes, I remember there were a couple of issues related with ASF. > Linux seems to have very complex logic to coexist with ASF/IPMI > firmware which I don't still understand its implications at this > time. bge(4) may need more robust code to handle that but datasheet > seems to show very limited information. Lack of ASF/IPMI capable > bge(4) controller also make me hard to experiment some code. Can understand the difficulty to debug such things, without having the hardware. So I did some more research myself, and found the bug. You said Linux was complicated, so I took a look at the Opensolaris bge source instead, to see how they do ASF things and I noticed the following comment ( http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/bge/bge_chip2.c ) == 5698 /* 5699 * The driver is supposed to notify ASF that the OS is still running 5700 * every three seconds, otherwise the management server may attempt 5701 * to reboot the machine. If it hasn't actually failed, this is 5702 * not a desirable result. However, this isn't running as a real-time 5703 * thread, and even if it were, it might not be able to generate the 5704 * heartbeat in a timely manner due to system load. As it isn't a 5705 * significant strain on the machine, we will set the interval to half 5706 * of the required value. 5707 */ == What a coincidence, although not the entire system is rebooted, my network link went up & down every 3 seconds according to the switch. Seems FreeBSD only notifies ASF every 5 seconds. Attached a patch that reduces it to 2 seconds, and it solves the problem for me, with ASF enabled. Yours sincerely, Floris Bos --Boundary-00=_KJOUL+qsQkRfsLe Content-Type: text/x-patch; charset="UTF-8"; name="bge_asf_driver_up.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="bge_asf_driver_up.patch" --- if_bge.orig 2010-01-15 22:16:08.325626860 +0100 +++ if_bge.c 2010-01-15 22:16:58.724265514 +0100 @@ -3677,7 +3677,7 @@ if (sc->bge_asf_count) sc->bge_asf_count --; else { - sc->bge_asf_count = 5; + sc->bge_asf_count = 2; bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM_FW, BGE_FW_DRV_ALIVE); bge_writemem_ind(sc, BGE_SOFTWARE_GENNCOMM_FW_LEN, 4); --Boundary-00=_KJOUL+qsQkRfsLe-- From owner-freebsd-net@FreeBSD.ORG Fri Jan 15 22:49:07 2010 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 DE5F5106566B for ; Fri, 15 Jan 2010 22:49:07 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id 8DBA18FC0C for ; Fri, 15 Jan 2010 22:49:07 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so159859qwd.7 for ; Fri, 15 Jan 2010 14:49:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=l3EhAHzn3DoKdj/RN4BK9zpp/Q/Vp8IyYRjv9RZdIJA=; b=wFolDghju6zVufo/y8smxxjdEORRerJF1LVrYzItp8CsyD40/obnjOVmp9opjwU2kW dPmK//CEp0MFprPy+tiSZ8Kj57Z7jTtFongMWWxM9y+a+WMdu/Iw7PYnIOxhX/BgomxC s+Rw57E9Ndc87o6XTzsUYCbuNMmg7e7ThUVNQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=c4l36C2f39lr5cq5QChzxplpX3xwMu90PmrH71XoRNOmnmcgyp/79aOzXh8aKwGRw7 ebcrxHJxToRf0KAOJoBz8YqFO0ClEAJqBoCZL95UAhM4EVyzVb4uEDjrETupuGVV5mWJ ueok+K+OQURphxFAA11Wq17buXNa5kJ4s7Iow= Received: by 10.224.115.84 with SMTP id h20mr2647880qaq.289.1263595741415; Fri, 15 Jan 2010 14:49:01 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 23sm2067019qyk.3.2010.01.15.14.48.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 15 Jan 2010 14:48:59 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 15 Jan 2010 14:48:19 -0800 From: Pyun YongHyeon Date: Fri, 15 Jan 2010 14:48:19 -0800 To: Floris Bos Message-ID: <20100115224819.GK1228@michelle.cdnetworks.com> References: <201001140140.o0E1e5hr072464@freefall.freebsd.org> <201001150333.59107.info@je-eigen-domein.nl> <20100115185424.GG1228@michelle.cdnetworks.com> <201001152246.50315.info@je-eigen-domein.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201001152246.50315.info@je-eigen-domein.nl> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: kern/92090: [bge] bge: watchdog timeout -- resetting X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 22:49:07 -0000 On Fri, Jan 15, 2010 at 10:46:50PM +0100, Floris Bos wrote: > On Friday 15 January 2010 07:54:24 pm Pyun YongHyeon wrote: > > On Fri, Jan 15, 2010 at 03:33:58AM +0100, Floris Bos wrote: > > > On Friday 15 January 2010 01:53:16 am Pyun YongHyeon wrote: > > > > On Thu, Jan 14, 2010 at 09:48:56PM +0100, Floris Bos wrote: > > > > > On Thursday 14 January 2010 09:11:44 pm Pyun YongHyeon wrote: > > > > > > On Thu, Jan 14, 2010 at 09:08:02PM +0100, Floris Bos wrote: > > > > > > > On Thursday 14 January 2010 06:56:03 pm Pyun YongHyeon wrote: > > > > > > > > On Thu, Jan 14, 2010 at 04:33:19AM +0100, Floris Bos wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > On Thursday 14 January 2010 03:54:52 am Pyun YongHyeon wrote: > > > > > > > > > > > == > > > > > > > > > > > bge0: mem 0xdf900000-0xdf90ffff irq 16 at device 0.0 on pci32 > > > > > > > > > > > == > > > > > > > > > > > > > > > > > > > > > > After boot, the network works for about 5 seconds, barely enough time to get an IP by DHCP, and sent a ping or 2. > > > > > > > > > > > Then network connectivity goes down, and after some time there is a "bge0: watchdog timeout -- resetting" message. > > > > > > > > > > > > > > > > > > > > > > Then network works again for 5 seconds, and goes down again. All the time, repeatedly. > > > > > > > > > > > > > > > > > > > > > > The system works fine under Ubuntu. So I assume the hardware is ok. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm not sure but it looks like you have a BCM5784 controller. What is > > > > > > > > > > the output of "devinfo -rv | grep phy"? > > > > > > > > > > > > > > > > > > == > > > > > > > > > ukphy0 pnpinfo oui=0x50ef model=0x3a rev=0x4 at phyno=1 > > > > > > > > > ukphy1 pnpinfo oui=0x50ef model=0x3a rev=0x4 at phyno=1 > > > > > > > > > == > > > > > > > > > > > > > > > > Support for the PHY was added in r202269. > > > > > > > > Please try again after applying the change. Or you can download > > > > > > > > sys/dev/mii/miidevs and sys/dev/mii/brgphy.c from HEAD and rebuild > > > > > > > > kernel. > > > > > > > > > > > > > > Fetched the latest source using CVS on another computer, and transferred it to the system concerned by USB stick. > > > > > > > Rebuild the kernel, but the problem is still there. > > > > > > > > > > > > > Would you show me full dmesg output including "watchodg timeout" > > > > > > messages? > > > > > > > > > > === > > > > > Copyright (c) 1992-2010 The FreeBSD Project. > > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > > > > The Regents of the University of California. All rights reserved. > > > > > > > > [...] > > > > > > > > > bge0: mem 0xdf900000-0xdf90ffff irq 16 at device 0.0 on pci32 > > > > > miibus0: on bge0 > > > > > brgphy0: PHY 1 on miibus0 > > > > > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > > > > > bge0: Ethernet address: f4:ce:46:0f:2a:2c > > > > > bge0: [FILTER] > > > > > pcib4: irq 16 at device 28.5 on pci0 > > > > > pci34: on pcib4 > > > > > bge1: mem 0xdfa00000-0xdfa0ffff irq 17 at device 0.0 on pci34 > > > > > miibus1: on bge1 > > > > > brgphy1: PHY 1 on miibus1 > > > > > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > > > > > bge1: Ethernet address: f4:ce:46:0f:2a:2d > > > > > bge1: [FILTER] > > > > > > > > [...] > > > > > > > > Would you give attached patch try? I don't know whether it help > > > > or not though. I couldn't find any related information for possible > > > > clue of the issue in publicly available datasheet. > > > > > > The patch did not make any difference. > > > > > > > > > However I did notice something else odd. > > > The problem only occurs on bge0, the second interface bge1 does work. > > > > > > I grabbed the U57DIAG diagnostic boot CD from the Broadcom site, and noticed that the first interface has ASF enabled, while the second one has not. > > > I disabled ASF by doing: > > > > > > = > > > b57udiag -cmd > > > setasf -d > > > == > > > > > > And now the first interface also works properly. > > > > > > > Glad to hear you solved the issue. I totally forgot CURRENT enabled > > ASF support by default(hw.bge.allow_asf). > > > > > So there is something with the ASF stuff that conflicts with FreeBSD. > > > The IPMI card of the system is configured to use a dedicated 3rd LAN port, and is NOT sharing bge0. > > > But perhaps the NIC is initialized differently nevertheless when ASF firmware is enabled, and that is causing issues? > > > > > > > Yes, I remember there were a couple of issues related with ASF. > > Linux seems to have very complex logic to coexist with ASF/IPMI > > firmware which I don't still understand its implications at this > > time. bge(4) may need more robust code to handle that but datasheet > > seems to show very limited information. Lack of ASF/IPMI capable > > bge(4) controller also make me hard to experiment some code. > > Can understand the difficulty to debug such things, without having the hardware. > So I did some more research myself, and found the bug. > > You said Linux was complicated, so I took a look at the Opensolaris bge source instead, to see how they do ASF things and I noticed the following comment ( http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/bge/bge_chip2.c ) > > == > 5698 /* > 5699 * The driver is supposed to notify ASF that the OS is still running > 5700 * every three seconds, otherwise the management server may attempt > 5701 * to reboot the machine. If it hasn't actually failed, this is > 5702 * not a desirable result. However, this isn't running as a real-time > 5703 * thread, and even if it were, it might not be able to generate the > 5704 * heartbeat in a timely manner due to system load. As it isn't a > 5705 * significant strain on the machine, we will set the interval to half > 5706 * of the required value. > 5707 */ > == > > What a coincidence, although not the entire system is rebooted, my network link went up & down every 3 seconds according to the switch. > > Seems FreeBSD only notifies ASF every 5 seconds. Attached a patch that reduces it to 2 seconds, and it solves the problem for me, with ASF enabled. > Nice catch! Thanks a lot! Actually I guess there is another bug in ASF handling. I'll request CFT to list and see how other bge(4) controllers work. > > Yours sincerely, > > Floris Bos From owner-freebsd-net@FreeBSD.ORG Fri Jan 15 23:15:44 2010 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 57AF8106566C for ; Fri, 15 Jan 2010 23:15:44 +0000 (UTC) (envelope-from Brett.Lee@Sun.COM) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by mx1.freebsd.org (Postfix) with ESMTP id 355A78FC12 for ; Fri, 15 Jan 2010 23:15:44 +0000 (UTC) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o0FNFhpc012398 for ; Fri, 15 Jan 2010 23:15:43 GMT MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_P8g99S1K55fVaaWxTR7Lmg)" Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KWB00K009S0I400@mail-amer.sun.com> for freebsd-net@freebsd.org; Fri, 15 Jan 2010 16:15:43 -0700 (MST) Received: from [192.168.1.11] ([unknown] [10.80.64.1]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KWB001DU9Y75QB0@mail-amer.sun.com> for freebsd-net@freebsd.org; Fri, 15 Jan 2010 16:15:43 -0700 (MST) Date: Fri, 15 Jan 2010 16:15:37 -0700 From: Brett Lee Sender: Brett.Lee@Sun.COM To: freebsd-net@freebsd.org Message-id: <4B50F719.5040402@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: DHCP6 client 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, 15 Jan 2010 23:15:44 -0000 This is a multi-part message in MIME format. --Boundary_(ID_P8g99S1K55fVaaWxTR7Lmg) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Hello - Am using FreeBSD 6.3 as a dhcp6 client, trying to get DDNSv6 operational in this environment. When I execute 'dhcp6c -d lnc0' from the command line, the following messages are logged on the (ISC 4.1.0p1) DHCP6 server: Solicit message from fe80::20c:29ff:fef3:a5de port 546, transaction ID 0xB3D95D Unable to pick client prefix: no IPv6 prefix pools on this shared network Sending Advertise to fe80::20c:29ff:fef3:a5de port 546 Am confused by the message above, in particular the "prefix pools", as this host obtains the "global address" prefix and configures both link local and global addresses via SLAAC. Surely this can't be the same prefix. Equally confusing is that the Solaris hosts on this LAN have no problem getting v6 addresses via this DHCP server, and there seems to be plenty of free leases available. Does FreeBSD 6.3 DHCP6 client need a "prefix", or a "pool" of them to be delivered by the server? Obviously I'm a little bit confused :) and am thinking the problem is with the dhcpd.conf file. Hoping for some clarification or direction. Configs are below. Thanks for your guidance/suggestions! -Brett Client: [root@freebsdvm ~]# ifconfig -a lnc0: flags=108843 mtu 1500 inet6 fe80::20c:29ff:fef3:a5de%lnc0 prefixlen 64 scopeid 0x1 inet 192.168.1.94 netmask 0xffffff00 broadcast 192.168.1.255 inet6 2bad:0:564:1:20c:29ff:fef3:a5de prefixlen 64 autoconf ether 00:0c:29:f3:a5:de plip0: flags=108810 mtu 1500 lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 [root@freebsdvm ~]# grep -v '#' /usr/local/etc/dhcp6c.conf interface lnc0 { send ia-pd 0; }; id-assoc pd { prefix-interface lnc0 { sla-id 1; }; }; [root@freebsdvm ~]# Server: [root@solaris10u4sparc named]# grep iaaddr /var/db/dhcpd6.leases | sort | uniq iaaddr 2bad:0:564:1::12 { iaaddr 2bad:0:564:1::18 { iaaddr 2bad:0:564:1::19 { iaaddr 2bad:0:564:2::18 { iaaddr 2bad:0:564:2::19 { iaaddr 2bad:0:564:3::18 { [root@solaris10u4sparc named]# grep -v '#' /etc/dhcpd.conf | egrep '[A-Z]|[a-z]|[0-9]' authoritative; include "/etc/rndc.key"; ddns-update-style interim; ddns-domainname "ipv6.apevt.local"; ddns-rev-domainname "in-addr.arpa"; ignore client-updates; zone ipv6.apevt.local. { primary 192.168.1.23; key "rndc-key"; log-facility local6; min-lease-time 60; default-lease-time 3600; max-lease-time 43200; option domain-name "ipv6.apevt.local"; option domain-name-servers 192.168.1.254, 192.168.1.23; option dhcp.domain-search "ipv6.apevt.local, apevt.local"; option dhcp6.domain-search "ipv6.apevt.local, apevt.local"; option dhcp6.name-servers 2bad:0:564:1:203:baff:fee8:36f2, 2bad:0:564:2:203:baff:fee8:36f3, 2bad:0:564:3:203:baff:fee8:36f4; subnet6 2bad:0000:0564:0001::/64 { allow unknown-clients; min-lease-time 60; default-lease-time 60; max-lease-time 60; range6 2bad:0000:0564:0001::10 2bad:0000:0564:0001::19; subnet6 2bad:0000:0564:0002::/64 { allow unknown-clients; min-lease-time 60; default-lease-time 60; max-lease-time 60; range6 2bad:0000:0564:0002::10 2bad:0000:0564:0002::19; subnet6 2bad:0000:0564:0003::/64 { allow unknown-clients; min-lease-time 60; default-lease-time 60; max-lease-time 60; range6 2bad:0000:0564:0003::10 2bad:0000:0564:0003::19; [root@solaris10u4sparc named]# --Boundary_(ID_P8g99S1K55fVaaWxTR7Lmg)-- From owner-freebsd-net@FreeBSD.ORG Sat Jan 16 12:39:26 2010 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 D4DD3106566C; Sat, 16 Jan 2010 12:39:26 +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 AC2708FC0C; Sat, 16 Jan 2010 12:39:26 +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 o0GCdQaZ056049; Sat, 16 Jan 2010 12:39:26 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0GCdQMi056045; Sat, 16 Jan 2010 12:39:26 GMT (envelope-from linimon) Date: Sat, 16 Jan 2010 12:39:26 GMT Message-Id: <201001161239.o0GCdQMi056045@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/142877: [hang] network-related repeatable 8.0-STABLE hard hang (kernel loop) 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, 16 Jan 2010 12:39:26 -0000 Old Synopsis: network-related repeatable 8.0-STABLE hard hang (kernel loop) New Synopsis: [hang] network-related repeatable 8.0-STABLE hard hang (kernel loop) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Jan 16 12:39:08 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=142877 From owner-freebsd-net@FreeBSD.ORG Sat Jan 16 13:29:48 2010 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 86B401065670 for ; Sat, 16 Jan 2010 13:29:48 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63903.mail.re1.yahoo.com (web63903.mail.re1.yahoo.com [69.147.97.118]) by mx1.freebsd.org (Postfix) with SMTP id 309618FC0C for ; Sat, 16 Jan 2010 13:29:47 +0000 (UTC) Received: (qmail 5534 invoked by uid 60001); 16 Jan 2010 13:29:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1263648584; bh=OC5yIWTG3ZjIZI8mo6Ew6eXY+naOXFuu/s5NUPdgmP4=; 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=vyAk0rkDHxAqYdYe/JfWJlGh5mZdFJ4T2xTs8qemXLTsHDZ7dsxAGDznDiejMZNJ3Q+p2vVG0eE7gFx6Jq4y4LD9ThxR9UVEyCbN7q+m5pXkimKgdPk9Nr/jaKHnD1vaHcz88NVJGFBM8C32mHJRNCmS3RDMLtSQOL03jIg0fqI= 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=6fsJusHTHeuWGZEeEeYzO8PPWO7VxL3AylHE0frS/C178JC9Vbnf+yIMYkP+jDIgCgQfbP3Pj65JBVNkZfFX3cypxMKF3CYlryc/jLRach3/Te83o7v+ytjhFTzgRzhAuw4vOEG83DszWbGb0n8UogKVnWQuHC2MxpEnpzUtvR4=; Message-ID: <965936.5529.qm@web63903.mail.re1.yahoo.com> X-YMail-OSG: VW5dx04VM1mG7AF6mpfDlU_6VVUQJ6b4hsHy19.Ivz3irP33BBHyH7cD5vvUksJWjo69WVun8DI3UlES._Uli_tSxf2WqMFjfhILKDInGa4L_m.YTNK89wp3JYHCRc4mWZ1DcALs.WHYg44aq2vklREQz92Nmvg3i70zrtRtN25NY9cz3PI6HjM0ovuMFsQtRQxXohp.aRPYSz0RY_YqOfJ5YgItjigV1EdSWna5C9cMDYBk_5hGtrYHWf4MXrDXBHyyJwCWgikWCx89nRM9to3MAsvA1M75qzd0ZaU- Received: from [98.203.21.152] by web63903.mail.re1.yahoo.com via HTTP; Sat, 16 Jan 2010 05:29:44 PST X-Mailer: YahooMailClassic/9.0.20 YahooMailWebService/0.8.100.260964 Date: Sat, 16 Jan 2010 05:29:44 -0800 (PST) From: Barney Cordoba To: Sebastian Hyrwall In-Reply-To: <4B504290.5020506@keff.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 7.2 vs Linux in routing 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: Sat, 16 Jan 2010 13:29:48 -0000 =0A=0A--- On Fri, 1/15/10, Sebastian Hyrwall wrote:=0A=0A> Fr= om: Sebastian Hyrwall =0A> Subject: FreeBSD 7.2 vs Linux in ro= uting performance=0A> To: freebsd-net@freebsd.org=0A> Date: Friday, January= 15, 2010, 5:25 AM=0A> Hi=0A> =0A> I have to identical x86 routers with the= following=0A> specifications,=0A> =0A> hw.model: Intel(R) Atom(TM) CPU=A0= =0A> 330=A0=A0=A0@ 1.60GHz=0A> hw.physmem: 2132996096=0A> hw.usermem: 17872= 52736=0A> hw.realmem: 2146041856=0A> 2x re0: 8168/8168B/8168C/= 8168CP/8168D/8111B/8111C/8111CP PCIe=0A> Gigabit Ethernet> port 0xd800-0xd8= ff mem=0A> 0xfeaff000-0xfeafffff,0xfdef0000-0xfdefffff irq 16 at device=0A>= 0.0 on pci2=0A> =0A> I know it's not really the best equipment to use in= =0A> gbit-enviroments but that is irrelevant here.=0A> =0A> One of these ru= ns FreeBSD 7.2 (R-p4) and the other Linux=0A> 2.6.31.5.=0A> =0A> Without pf= /iptables loaded the FreeBSD-server maxes out at=0A> 35MB/s when it comes t= o forwarding between the two NICs=0A> (simple http-transfer used for testin= g).=0A> The Linux-server pushes 90-100MB/s between the NICs with=0A> the sa= me test. Both servers are connected the same way to=0A> the network (I swap= them between the testing).=0A> =0A> Any suggestions on where the gigantic = performance loss=0A> might be and how to fix it?=0A> =0A> I intend to switc= h FreeBSD 8 in the coming month and maybe=0A> that will fix the problem but= I am hoping it's also fixable=0A> in 7.2.=0A> =0A=0AThe equipment really I= S relevant. The FreeBSD realtek driver is=0Aparticularly sucky. As with any= free OS, some drivers are good, =0Aand most are not. So try something else= . Anything written by=0ABill Paul is assembly-line quality by definition.= =0A=0A=0ABarney=0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Sat Jan 16 13:31:52 2010 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 79157106566C for ; Sat, 16 Jan 2010 13:31:52 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63906.mail.re1.yahoo.com (web63906.mail.re1.yahoo.com [69.147.97.121]) by mx1.freebsd.org (Postfix) with SMTP id 233108FC15 for ; Sat, 16 Jan 2010 13:31:51 +0000 (UTC) Received: (qmail 68902 invoked by uid 60001); 16 Jan 2010 13:31:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1263648704; bh=q4kTVs84BsFXWfDtK2rd2TwJndPFkuirtdyrnlFsEhA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=n2OBbb+o6zfcCqj5OGY4VhOxLsD7LN4qEqiZijJKhevVCRzl0gnPXF5bNH9zPI6bzXrN39tpGBUqKLKCJ/xgTwrGSlbfEfw5BDLGIpcPhZuLopT6eId8QadIhotHX5CaiQ0LJHxjyDjWhi2t3soHJmf4aBFtSWwQzuby/gvAQco= 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:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=LDLbS0cJ1ofdFerru4djq6kcpQXfySf75+TEsp85SayYkkemG0exUReVFL9xNs+hd+8XvNMeUcCBYVZq78xIj4dvkUf1KnGtUxehCRUAxpq8I3cjJxaae+AE29q9L+t6hArezzF4YtPGywWUCQ2alj7BAYazzyzk0WnqJm2lq7o=; Message-ID: <875287.68136.qm@web63906.mail.re1.yahoo.com> X-YMail-OSG: xBvWH_oVM1lb_KqYOMHTWct3lm.e.4kO2bN_Feg0uvJHBtUXkupM1KaGMA7033BHyC.HjwDJvB.BFSdeMv8ZWdmk0u64ljc9bIZFWRrBktgg1IE0y4BWGyH5MacOHv.9ADrgIyc2NE8n6BfyW_twFFUjjaqWhaq_SRn9_.thcKjAtYIrEli5ryyW._03Gj3AVhPx4.OwY9_YgCIEgW5cv3zFMg9DFG.BV3k_pql_4uHF4WilJfTXDqMBb0le0HoJn93gSw0yg2o- Received: from [98.203.21.152] by web63906.mail.re1.yahoo.com via HTTP; Sat, 16 Jan 2010 05:31:44 PST X-Mailer: YahooMailClassic/9.0.20 YahooMailWebService/0.8.100.260964 Date: Sat, 16 Jan 2010 05:31:44 -0800 (PST) From: Barney Cordoba To: freebsd-net@freebsd.org, Callum Gibson In-Reply-To: <20100114223241.GA67640@omma.gibson.athome> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: lagg doesn't fail back to master 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, 16 Jan 2010 13:31:52 -0000 =0A=0A--- On Thu, 1/14/10, Callum Gibson wro= te:=0A=0A> From: Callum Gibson =0A> Subject: = Re: lagg doesn't fail back to master=0A> To: freebsd-net@freebsd.org=0A> Da= te: Thursday, January 14, 2010, 5:33 PM=0A> On 12Jan10 14:25, Callum Gibson= =0A> wrote:=0A> }I have the following in my rc.conf:=0A> }=0A> }wlans_bwi0= =3D"wlan0"=0A> }ifconfig_bwi0=3D"ether XXX"=0A> }ifconfig_wlan0=3D"WPA mode= 11g"=0A> }cloned_interfaces=3D"lagg0"=0A> }ifconfig_lagg0=3D"SYNCDHCP lagg= proto failover laggport bge0=0A> laggport wlan0"=0A> }=0A> }This seems to w= ork fine at boot. However, once I plug=0A> wired back in,=0A> }lagg doesn't= switch back to the master. Here is what=0A> ifconfig is showing:=0A> =0A> = Thanks for the replies. For the list, the solution was to=0A> add the follo= wing=0A> to rc.conf:=0A> =0A> ifconfig_bge0=3D"up"=0A> =0A> =A0 =A0 C=0A=0A= LAGG should up (init) the port on add, so if it doesn't then=0Ayour solutio= n is really a work-around to a bug in LAGG.=0A=0ABarney=0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Sat Jan 16 21:08:53 2010 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 43BE41065676; Sat, 16 Jan 2010 21:08:53 +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 1A9F48FC17; Sat, 16 Jan 2010 21:08:53 +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 o0GL8qdT096529; Sat, 16 Jan 2010 21:08:52 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0GL8qs9096525; Sat, 16 Jan 2010 21:08:52 GMT (envelope-from gavin) Date: Sat, 16 Jan 2010 21:08:52 GMT Message-Id: <201001162108.o0GL8qs9096525@freefall.freebsd.org> To: gavin@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: bin/82185: [patch] ndp(8) can delete the incorrect entry 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, 16 Jan 2010 21:08:53 -0000 Old Synopsis: [patch] ndp(8) command bug New Synopsis: [patch] ndp(8) can delete the incorrect entry Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Sat Jan 16 21:06:40 UTC 2010 Responsible-Changed-Why: Over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=82185