From owner-freebsd-net@FreeBSD.ORG Sun Jul 10 03:44:19 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84DEA1065670 for ; Sun, 10 Jul 2011 03:44:19 +0000 (UTC) (envelope-from remy.sanchez@hyperthese.net) Received: from slow3-v.mail.gandi.net (slow3-v.mail.gandi.net [217.70.178.89]) by mx1.freebsd.org (Postfix) with ESMTP id 3E5A88FC1B for ; Sun, 10 Jul 2011 03:44:19 +0000 (UTC) X-WhiteListed: mail was accepted with no delay X-WhiteListed: mail was accepted with no delay Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by slow3-v.mail.gandi.net (Postfix) with ESMTP id 933023812A for ; Sun, 10 Jul 2011 05:21:55 +0200 (CEST) Received: from magi.localnet (unknown [IPv6:2a01:e35:2e3d:8820:21f:16ff:feb6:9aac]) (Authenticated sender: remy.sanchez@hyperthese.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 51D5A172067 for ; Sun, 10 Jul 2011 05:14:01 +0200 (CEST) From: =?iso-8859-1?q?R=E9my_Sanchez?= To: freebsd-net@freebsd.org Date: Sun, 10 Jul 2011 05:13:47 +0200 User-Agent: KMail/1.13.7 (Linux/2.6.39-2-amd64; KDE/4.6.3; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2236973.ytWJj21arR"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201107100513.47337.remy.sanchez@hyperthese.net> Subject: RFC 6296 (NPT v6) 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 Jul 2011 03:44:19 -0000 --nextPart2236973.ytWJj21arR Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I was wondering if they were anyone currently implementing NPTv6 for FreeBS= D ? If nobody is, since I need this feature and that the RFC is quite simple, I= =20 think I'll implement it (or run out of time trying to). However, it looks l= ike=20 you can't divert IPv6, and then I don't know what would be the best option = to=20 implement it: using netgraph might be a "cleaner" way to do it, however=20 hacking directly into ipfw might be more direct. What do you think ? Thanks, =2D-=20 R=E9my Sanchez http://hyperthese.net/ --nextPart2236973.ytWJj21arR Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk4ZGOsACgkQpMMQ4XyIN1bmTwCfc+RipN92YBMTGB4GJysMfRmi s1cAoKJX7S6mQfexh0+p4Mkg0zEDOCVv =ISWV -----END PGP SIGNATURE----- --nextPart2236973.ytWJj21arR-- From owner-freebsd-net@FreeBSD.ORG Sun Jul 10 07:38:42 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DF72106564A for ; Sun, 10 Jul 2011 07:38:42 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 0F1D58FC0C for ; Sun, 10 Jul 2011 07:38:41 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id D7F7825D37C3; Sun, 10 Jul 2011 07:38:40 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id D6B6A15A8C16; Sun, 10 Jul 2011 07:38:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id HhYRU5vE1Hms; Sun, 10 Jul 2011 07:38:37 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 7251815A8BEB; Sun, 10 Jul 2011 07:38:37 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: "Bjoern A. Zeeb" In-Reply-To: <201107100513.47337.remy.sanchez@hyperthese.net> Date: Sun, 10 Jul 2011 07:38:36 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6ED7645C-6E24-41BB-B5AC-9858D5E94B10@lists.zabbadoz.net> References: <201107100513.47337.remy.sanchez@hyperthese.net> To: =?iso-8859-1?Q?R=E9my_Sanchez?= X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: RFC 6296 (NPT v6) 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 Jul 2011 07:38:42 -0000 On Jul 10, 2011, at 3:13 AM, R=E9my Sanchez wrote: > I was wondering if they were anyone currently implementing NPTv6 for = FreeBSD ? >=20 > If nobody is, since I need this feature and that the RFC is quite = simple, I=20 > think I'll implement it (or run out of time trying to). However, it = looks like=20 > you can't divert IPv6, and then I don't know what would be the best = option to=20 > implement it: using netgraph might be a "cleaner" way to do it, = however=20 > hacking directly into ipfw might be more direct. >=20 > What do you think ? pf allows you do do prefix rewriting with binat at least, like: binat on $extif inet6 from $my_v6_ula_48 to ! = -> $my_v6_external_48 --=20 Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-net@FreeBSD.ORG Sun Jul 10 12:57:33 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15963106564A for ; Sun, 10 Jul 2011 12:57:33 +0000 (UTC) (envelope-from remy.sanchez@hyperthese.net) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by mx1.freebsd.org (Postfix) with ESMTP id C5BA68FC08 for ; Sun, 10 Jul 2011 12:57:32 +0000 (UTC) Received: from magi.localnet (unknown [IPv6:2a01:e35:2e3d:8820:21f:16ff:feb6:9aac]) (Authenticated sender: remy.sanchez@hyperthese.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 3A421172070 for ; Sun, 10 Jul 2011 14:57:21 +0200 (CEST) From: =?iso-8859-1?q?R=E9my_Sanchez?= To: freebsd-net@freebsd.org Date: Sun, 10 Jul 2011 14:56:58 +0200 User-Agent: KMail/1.13.7 (Linux/2.6.39-2-amd64; KDE/4.6.3; x86_64; ; ) References: <201107100513.47337.remy.sanchez@hyperthese.net> <6ED7645C-6E24-41BB-B5AC-9858D5E94B10@lists.zabbadoz.net> In-Reply-To: <6ED7645C-6E24-41BB-B5AC-9858D5E94B10@lists.zabbadoz.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4492168.CMSAk4gJO6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201107101457.05577.remy.sanchez@hyperthese.net> Subject: Re: RFC 6296 (NPT v6) 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 Jul 2011 12:57:33 -0000 --nextPart4492168.CMSAk4gJO6 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Sunday 10 July 2011 09:38:36 Bjoern A. Zeeb wrote: > pf allows you do do prefix rewriting with binat at least, like: >=20 > binat on $extif inet6 from $my_v6_ula_48 to ! -> > $my_v6_external_48 Well, that's not quite it I think, because it looks like to be "plain old" = NAT=20 whereas RFC 6296 do not touch upper layers. (And besides, I use ipfw and not pf) =2D-=20 R=E9my Sanchez http://hyperthese.net/ --nextPart4492168.CMSAk4gJO6 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk4ZoZoACgkQpMMQ4XyIN1bHpACgwD29H6zxOsuyJVrUv5KXhtXq c/sAn2u7PiLZQ/0YjrETVyrhmg8EW9dt =MALu -----END PGP SIGNATURE----- --nextPart4492168.CMSAk4gJO6-- From owner-freebsd-net@FreeBSD.ORG Mon Jul 11 04:28:02 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33ED6106564A; Mon, 11 Jul 2011 04:28:02 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0C8618FC0C; Mon, 11 Jul 2011 04:28:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6B4S1HY072382; Mon, 11 Jul 2011 04:28:01 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6B4S10g072378; Mon, 11 Jul 2011 04:28:01 GMT (envelope-from linimon) Date: Mon, 11 Jul 2011 04:28:01 GMT Message-Id: <201107110428.p6B4S10g072378@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/152036: [libc] getifaddrs(3) returns truncated sockaddrs for netmasks 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 Jul 2011 04:28:02 -0000 Old Synopsis: getifaddrs(3) returns truncated sockaddrs for netmasks New Synopsis: [libc] getifaddrs(3) returns truncated sockaddrs for netmasks Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jul 11 04:27:19 UTC 2011 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=152036 From owner-freebsd-net@FreeBSD.ORG Mon Jul 11 11:07:07 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C94B9106566B for ; Mon, 11 Jul 2011 11:07:07 +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 B80278FC21 for ; Mon, 11 Jul 2011 11:07:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6BB77hu077059 for ; Mon, 11 Jul 2011 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6BB77hN077057 for freebsd-net@FreeBSD.org; Mon, 11 Jul 2011 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 11 Jul 2011 11:07:07 GMT Message-Id: <201107111107.p6BB77hN077057@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 Jul 2011 11:07:07 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/158426 net [e1000] [panic] _mtx_lock_sleep: recursed on non-recur o kern/158156 net [bce] bce driver shows "no carrier" on IBM blade (HS22 f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157429 net [re] Realtek RTL8169 doesn't work with re(4) o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156978 net [lagg][patch] Take lagg rlock before checking flags o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155604 net [flowtable] Flowtable excessively caches dest MAC addr o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155585 net [tcp] [panic] tcp_output tcp_mtudisc loop until kernel o kern/155498 net [ral] ral(4) needs to be resynced with OpenBSD's to ga o kern/155420 net [vlan] adding vlan break existent vlan o bin/155365 net [patch] routed(8): if.c in routed fails to compile if o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/155004 net [bce] [panic] kernel panic in bce0 driver o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t p kern/154831 net [arp] [patch] arp sysctl setting log_arp_permanent_mod o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o bin/150642 net netstat(1) doesn't print anything for SCTP sockets o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o bin/145934 net [patch] add count option to netstat(1) o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134931 net [route] Route messages sent to all socket listeners re o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre 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/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/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 kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/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 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/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125442 net [carp] [lagg] CARP combined with LAGG causes system pa o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123045 net [ng_mppc] ng_mppc_decompress - disabling node o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o 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 kern/118727 net [netgraph] [patch] [request] add new ng_pf module 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 bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 380 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jul 11 11:42:46 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A96F106564A for ; Mon, 11 Jul 2011 11:42:46 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (unknown [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id A63CB8FC13 for ; Mon, 11 Jul 2011 11:42:45 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p6BBggLO079327 for ; Mon, 11 Jul 2011 18:42:42 +0700 (NOVST) (envelope-from egrosbein@rdtc.ru) Message-ID: <4E1AE1AD.4020907@rdtc.ru> Date: Mon, 11 Jul 2011 18:42:37 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: "net@freebsd.org" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Repeating kernel panic within dummynet 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 Jul 2011 11:42:46 -0000 Hi! My FreeBSD 8.2/amd64 routers use dummynet heavily and keep panic with the *same* KDB backtrace: dummynet: bad switch -256! Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read instruction, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xffffff81229d9a10 frame pointer = 0x28:0xffffff81229d9a40 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (dummynet) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff801aaaca = db_trace_self_wrapper+0x2a kdb_backtrace() at 0xffffffff80329667 = kdb_backtrace+0x37 panic() at 0xffffffff802f6cb7 = panic+0x187 trap_fatal() at 0xffffffff804d8b50 = trap_fatal+0x290 trap_pfault() at 0xffffffff804d8f2f = trap_pfault+0x28f trap() at 0xffffffff804d940f = trap+0x3df calltrap() at 0xffffffff804c0b44 = calltrap+0x8 --- trap 0xc, rip = 0, rsp = 0xffffff81229d9a10, rbp = 0xffffff81229d9a40 --- uart_z8530_class() at 0 mb_dtor_pack() at 0xffffffff802e4787 = mb_dtor_pack+0x37 uma_zfree_arg() at 0xffffffff8049ba5a = uma_zfree_arg+0x3a m_freem() at 0xffffffff803556a7 = m_freem+0x37 dummynet_send() at 0xffffffff803e909d = dummynet_send+0x2d dummynet_task() at 0xffffffff803e93c6 = dummynet_task+0x1c6 taskqueue_run_locked() at 0xffffffff80335a65 = taskqueue_run_locked+0x85 taskqueue_thread_loop() at 0xffffffff80335bfe = taskqueue_thread_loop+0x4e fork_exit() at 0xffffffff802ca4bf = fork_exit+0x11f fork_trampoline() at 0xffffffff804c108e = fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff81229d9d00, rbp = 0 --- Uptime: 2d5h17m39s Dumping 4087 MB (4 chunks) chunk 0: 1MB (150 pages) ... ok chunk 1: 3575MB (915072 pages) 3559 3543 3527 3511 3495 3479 It does not finish writing dump and hangs until IPMI watchdog reboots the box. I've tried to use debug.minidump=1 but it still hangs while crashdumps is generating and stops responding to Ctrl-Alt-ESC meantime. Sadly, I cannot add options INVARIANTS to the kernel because it makes my mpd-based routers to panic very often (every 2-3 hours) due to famous 'dangling pointer' problem - PPPoE user disconnects, its ngXXX interface got removed, then its traffic goes out various system queues (netisr, dummynet etc.) and another kind of panic occurs due to INVARIANTS' references to non-existent ifp. Please help. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Jul 11 11:51:50 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9D9B1065672 for ; Mon, 11 Jul 2011 11:51:50 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (unknown [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 22CFC8FC14 for ; Mon, 11 Jul 2011 11:51:49 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p6BBpfkU079375; Mon, 11 Jul 2011 18:51:41 +0700 (NOVST) (envelope-from egrosbein@rdtc.ru) Message-ID: <4E1AE3C8.8030708@rdtc.ru> Date: Mon, 11 Jul 2011 18:51:36 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Vlad Galu References: <4E1AE1AD.4020907@rdtc.ru> <833EECF8-245B-4085-B853-AC753DBE0D19@dudu.ro> In-Reply-To: <833EECF8-245B-4085-B853-AC753DBE0D19@dudu.ro> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: "net@freebsd.org" Subject: Re: Repeating kernel panic within dummynet 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 Jul 2011 11:51:50 -0000 11.07.2011 18:45, Vlad Galu пишет: > > On Jul 11, 2011, at 1:42 PM, Eugene Grosbein wrote: > >> Hi! >> >> My FreeBSD 8.2/amd64 routers use dummynet heavily >> and keep panic with the *same* KDB backtrace: >> >> dummynet: bad switch -256! Forgot to mention that I use io_fast dummynet mode and have increased pipe lengths: net.inet.ip.dummynet.pipe_slot_limit=1000 net.inet.ip.dummynet.io_fast=1 Distinct pipes do really use long lengths. >> Sadly, I cannot add options INVARIANTS to the kernel because it makes my mpd-based >> routers to panic very often (every 2-3 hours) due to famous 'dangling pointer' >> problem - PPPoE user disconnects, its ngXXX interface got removed, then its traffic >> goes out various system queues (netisr, dummynet etc.) and another kind of panic >> occurs due to INVARIANTS' references to non-existent ifp. > > Hi Eugene, > If your ISR threads aren't already bound to CPUs, you can bind them and try using INVARIANTS. Please explain how to bind them. I have 4-core boxes with 4 NICs grouped to 2 laggs, one lagg(4) for uplink and another one for downlink. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Jul 11 12:02:29 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00B161065672 for ; Mon, 11 Jul 2011 12:02:29 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8E0298FC1C for ; Mon, 11 Jul 2011 12:02:28 +0000 (UTC) Received: by bwa20 with SMTP id 20so4298642bwa.13 for ; Mon, 11 Jul 2011 05:02:27 -0700 (PDT) Received: by 10.204.169.66 with SMTP id x2mr1547648bky.399.1310385747016; Mon, 11 Jul 2011 05:02:27 -0700 (PDT) Received: from [192.168.10.3] ([82.76.253.74]) by mx.google.com with ESMTPS id e16sm9266726bke.6.2011.07.11.05.02.24 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Jul 2011 05:02:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Vlad Galu In-Reply-To: <4E1AE3C8.8030708@rdtc.ru> Date: Mon, 11 Jul 2011 14:02:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <30BDDC28-275C-4DAA-9AC8-621F36A19D3B@dudu.ro> References: <4E1AE1AD.4020907@rdtc.ru> <833EECF8-245B-4085-B853-AC753DBE0D19@dudu.ro> <4E1AE3C8.8030708@rdtc.ru> To: Eugene Grosbein X-Mailer: Apple Mail (2.1084) Cc: "net@freebsd.org" Subject: Re: Repeating kernel panic within dummynet 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 Jul 2011 12:02:29 -0000 On Jul 11, 2011, at 1:51 PM, Eugene Grosbein wrote: > 11.07.2011 18:45, Vlad Galu =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >>=20 >> On Jul 11, 2011, at 1:42 PM, Eugene Grosbein wrote: >>=20 >>> Hi! >>>=20 >>> My FreeBSD 8.2/amd64 routers use dummynet heavily >>> and keep panic with the *same* KDB backtrace: >>>=20 >>> dummynet: bad switch -256! >=20 > Forgot to mention that I use io_fast dummynet mode > and have increased pipe lengths: >=20 > net.inet.ip.dummynet.pipe_slot_limit=3D1000 > net.inet.ip.dummynet.io_fast=3D1 >=20 > Distinct pipes do really use long lengths. >=20 >>> Sadly, I cannot add options INVARIANTS to the kernel because it = makes my mpd-based >>> routers to panic very often (every 2-3 hours) due to famous = 'dangling pointer' >>> problem - PPPoE user disconnects, its ngXXX interface got removed, = then its traffic >>> goes out various system queues (netisr, dummynet etc.) and another = kind of panic >>> occurs due to INVARIANTS' references to non-existent ifp. >>=20 >> Hi Eugene, >> If your ISR threads aren't already bound to CPUs, you can bind them = and try using INVARIANTS. >=20 > Please explain how to bind them. I have 4-core boxes with 4 NICs = grouped to 2 laggs, > one lagg(4) for uplink and another one for downlink. >=20 net.isr.bindthreads=3D1 I'm not sure how and if that would help your particular setup, but it = did so in Adrian Minta's recent netgraph/mpd experiments. According to = an off-list chat I had with him, the machine would panic unless the ISRs = were bound. > Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Jul 11 12:08:46 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C231A106566B for ; Mon, 11 Jul 2011 12:08:46 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (unknown [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 2A9B48FC14 for ; Mon, 11 Jul 2011 12:08:45 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p6BC8fww079484; Mon, 11 Jul 2011 19:08:41 +0700 (NOVST) (envelope-from egrosbein@rdtc.ru) Message-ID: <4E1AE7C4.60609@rdtc.ru> Date: Mon, 11 Jul 2011 19:08:36 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Vlad Galu References: <4E1AE1AD.4020907@rdtc.ru> <833EECF8-245B-4085-B853-AC753DBE0D19@dudu.ro> <4E1AE3C8.8030708@rdtc.ru> <30BDDC28-275C-4DAA-9AC8-621F36A19D3B@dudu.ro> In-Reply-To: <30BDDC28-275C-4DAA-9AC8-621F36A19D3B@dudu.ro> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: "net@freebsd.org" Subject: Re: Repeating kernel panic within dummynet 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 Jul 2011 12:08:46 -0000 11.07.2011 19:02, Vlad Galu пишет: > net.isr.bindthreads=1 > > I'm not sure how and if that would help your particular setup, but it did so in Adrian Minta's recent netgraph/mpd experiments. According to an off-list chat I had with him, the machine would panic unless the ISRs were bound. I disable ISR parallelism for my mpd routers using: net.isr.direct=1 net.isr.direct_force=1 At the other hand, there are other queues where traffic got delayed, not ISR only. Dummynet itself is an example. The router still panices with INVARIANTS too often. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Jul 11 12:12:27 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFBF21065670 for ; Mon, 11 Jul 2011 12:12:26 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 780608FC12 for ; Mon, 11 Jul 2011 12:12:26 +0000 (UTC) Received: by bwa20 with SMTP id 20so4308354bwa.13 for ; Mon, 11 Jul 2011 05:12:25 -0700 (PDT) Received: by 10.204.42.68 with SMTP id r4mr2742736bke.28.1310384755518; Mon, 11 Jul 2011 04:45:55 -0700 (PDT) Received: from [192.168.10.3] ([82.76.253.74]) by mx.google.com with ESMTPS id af13sm9915305bkc.7.2011.07.11.04.45.53 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Jul 2011 04:45:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Vlad Galu In-Reply-To: <4E1AE1AD.4020907@rdtc.ru> Date: Mon, 11 Jul 2011 13:45:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <833EECF8-245B-4085-B853-AC753DBE0D19@dudu.ro> References: <4E1AE1AD.4020907@rdtc.ru> To: Eugene Grosbein X-Mailer: Apple Mail (2.1084) Cc: "net@freebsd.org" Subject: Re: Repeating kernel panic within dummynet 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 Jul 2011 12:12:27 -0000 On Jul 11, 2011, at 1:42 PM, Eugene Grosbein wrote: > Hi! >=20 > My FreeBSD 8.2/amd64 routers use dummynet heavily > and keep panic with the *same* KDB backtrace: >=20 > dummynet: bad switch -256! >=20 >=20 > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > fault virtual address =3D 0x0 > fault code =3D supervisor read instruction, page not = present > instruction pointer =3D 0x20:0x0 > stack pointer =3D 0x28:0xffffff81229d9a10 > frame pointer =3D 0x28:0xffffff81229d9a40 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 0 (dummynet) > trap number =3D 12 > panic: page fault > cpuid =3D 0 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff801aaaca =3D = db_trace_self_wrapper+0x2a > kdb_backtrace() at 0xffffffff80329667 =3D kdb_backtrace+0x37 > panic() at 0xffffffff802f6cb7 =3D panic+0x187 > trap_fatal() at 0xffffffff804d8b50 =3D trap_fatal+0x290 > trap_pfault() at 0xffffffff804d8f2f =3D trap_pfault+0x28f > trap() at 0xffffffff804d940f =3D trap+0x3df > calltrap() at 0xffffffff804c0b44 =3D calltrap+0x8 > --- trap 0xc, rip =3D 0, rsp =3D 0xffffff81229d9a10, rbp =3D = 0xffffff81229d9a40 --- > uart_z8530_class() at 0 > mb_dtor_pack() at 0xffffffff802e4787 =3D mb_dtor_pack+0x37 > uma_zfree_arg() at 0xffffffff8049ba5a =3D uma_zfree_arg+0x3a > m_freem() at 0xffffffff803556a7 =3D m_freem+0x37 > dummynet_send() at 0xffffffff803e909d =3D dummynet_send+0x2d > dummynet_task() at 0xffffffff803e93c6 =3D dummynet_task+0x1c6 > taskqueue_run_locked() at 0xffffffff80335a65 =3D = taskqueue_run_locked+0x85 > taskqueue_thread_loop() at 0xffffffff80335bfe =3D = taskqueue_thread_loop+0x4e > fork_exit() at 0xffffffff802ca4bf =3D fork_exit+0x11f > fork_trampoline() at 0xffffffff804c108e =3D fork_trampoline+0xe > --- trap 0, rip =3D 0, rsp =3D 0xffffff81229d9d00, rbp =3D 0 --- > Uptime: 2d5h17m39s > Dumping 4087 MB (4 chunks) > chunk 0: 1MB (150 pages) ... ok > chunk 1: 3575MB (915072 pages) 3559 3543 3527 3511 3495 3479 >=20 >=20 > It does not finish writing dump and hangs until IPMI watchdog reboots = the box. > I've tried to use debug.minidump=3D1 but it still hangs while = crashdumps is generating > and stops responding to Ctrl-Alt-ESC meantime. >=20 > Sadly, I cannot add options INVARIANTS to the kernel because it makes = my mpd-based > routers to panic very often (every 2-3 hours) due to famous 'dangling = pointer' > problem - PPPoE user disconnects, its ngXXX interface got removed, = then its traffic > goes out various system queues (netisr, dummynet etc.) and another = kind of panic > occurs due to INVARIANTS' references to non-existent ifp. Hi Eugene, If your ISR threads aren't already bound to CPUs, you can bind them and = try using INVARIANTS. From owner-freebsd-net@FreeBSD.ORG Mon Jul 11 14:00:25 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08F97106566C for ; Mon, 11 Jul 2011 14:00:25 +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 BAE5F8FC29 for ; Mon, 11 Jul 2011 14:00:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6BE0Oov040564 for ; Mon, 11 Jul 2011 14:00:24 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6BE0ODA040563; Mon, 11 Jul 2011 14:00:24 GMT (envelope-from gnats) Date: Mon, 11 Jul 2011 14:00:24 GMT Message-Id: <201107111400.p6BE0ODA040563@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Sergey Kandaurov Cc: Subject: Re: kern/152036: [libc] getifaddrs(3) returns truncated sockaddrs for netmasks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sergey Kandaurov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 14:00:25 -0000 The following reply was made to PR kern/152036; it has been noted by GNATS. From: Sergey Kandaurov To: bug-followup@FreeBSD.org, kbyanc@gmail.com Cc: Subject: Re: kern/152036: [libc] getifaddrs(3) returns truncated sockaddrs for netmasks Date: Mon, 11 Jul 2011 17:59:47 +0400 [Some thoughts and testing...] This is rather a kernel bug, i.e. this is not a getifaddrs() bug. This is confirmed by (undocumented) ioctl SIOCGIFNETMASK. I found that the bug is manifested for ip4, and not for lladdr, ipv6. From owner-freebsd-net@FreeBSD.ORG Mon Jul 11 14:50:47 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB0851065674 for ; Mon, 11 Jul 2011 14:50:47 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (mail.ciam.ru [91.209.218.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7E7868FC21 for ; Mon, 11 Jul 2011 14:50:47 +0000 (UTC) Received: from dhcp170-19-red.yandex.net ([95.108.170.19] helo=dhcp170-205-red.yandex.net) by mail.ciam.ru with esmtpa (Exim 4.x) id 1QgHR6-000Pt2-Cl; Mon, 11 Jul 2011 18:26:12 +0400 Message-ID: <4E1B0804.1000309@FreeBSD.org> Date: Mon, 11 Jul 2011 18:26:12 +0400 From: Sergey Matveychuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9my_Sanchez?= References: <201107100513.47337.remy.sanchez@hyperthese.net> In-Reply-To: <201107100513.47337.remy.sanchez@hyperthese.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: RFC 6296 (NPT v6) 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 Jul 2011 14:50:47 -0000 10.07.2011 7:13, RИmy Sanchez wrote: > Hi, > > I was wondering if they were anyone currently implementing NPTv6 for FreeBSD ? > > If nobody is, since I need this feature and that the RFC is quite simple, I > think I'll implement it (or run out of time trying to). However, it looks like > you can't divert IPv6, and then I don't know what would be the best option to IPv6 patch for divert(4) was committed in HEAD a couple weeks ago by glebius@ (r223593). From owner-freebsd-net@FreeBSD.ORG Mon Jul 11 15:15:38 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E6CC106566C for ; Mon, 11 Jul 2011 15:15:38 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-245-Pennsylvania.hfc.comcastbusiness.net [75.149.8.245]) by mx1.freebsd.org (Postfix) with ESMTP id 0DC7A8FC27 for ; Mon, 11 Jul 2011 15:15:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id CB12F8BC003; Mon, 11 Jul 2011 11:17:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0owtknOeuEQ0; Mon, 11 Jul 2011 11:17:51 -0400 (EDT) Received: from riven.arriad.com (fw.arriad.com [10.0.0.16]) by zimbra.averesystems.com (Postfix) with ESMTPSA id 72D868BC01F; Mon, 11 Jul 2011 11:17:51 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Andrew Boyer In-Reply-To: <4E16E136.7030509@freebsd.org> Date: Mon, 11 Jul 2011 11:15:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1C53806A-9BA1-4626-BA1D-2D1922E30372@averesystems.com> References: <867h7zxvd2.fsf@kopusha.home.net> <4E158EB3.80203@freebsd.org> <86iprd99mi.fsf@kopusha.home.net> <4E16E136.7030509@freebsd.org> To: Andre Oppermann X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org, Mikolaj Golub Subject: MFC Re: soreceive_stream: issues with O_NONBLOCK 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 Jul 2011 15:15:38 -0000 On Jul 8, 2011, at 6:51 AM, Andre Oppermann wrote: > On 07.07.2011 21:24, Mikolaj Golub wrote: >>=20 >> On Thu, 07 Jul 2011 12:47:15 +0200 Andre Oppermann wrote: >>=20 >> AO> Please try this patch: >> AO> = http://people.freebsd.org/~andre/soreceive_stream.diff-20110707 >>=20 >> It works for me. No issues detected so far. Thanks. >=20 > Committed in r223863. Many thanks for testing! >=20 > --=20 > Andre Hello Andre, It appears that r197236 was never MFC'd, so soreceive_stream is still on = by default in stable/8. Would you be able to MFC it along with 223839 = and 223863? Thank you, Andrew -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-net@FreeBSD.ORG Mon Jul 11 15:18:26 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81590106564A for ; Mon, 11 Jul 2011 15:18:26 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-245-Pennsylvania.hfc.comcastbusiness.net [75.149.8.245]) by mx1.freebsd.org (Postfix) with ESMTP id 40C118FC18 for ; Mon, 11 Jul 2011 15:18:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id 2ECC6446002; Mon, 11 Jul 2011 11:20:46 -0400 (EDT) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mM2Q-VJR23X; Mon, 11 Jul 2011 11:20:39 -0400 (EDT) Received: from riven.arriad.com (fw.arriad.com [10.0.0.16]) by zimbra.averesystems.com (Postfix) with ESMTPSA id B0917446001; Mon, 11 Jul 2011 11:20:38 -0400 (EDT) From: Andrew Boyer Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Jul 2011 11:18:17 -0400 Message-Id: <5BAB0947-468A-426B-A2A9-90E340FAB7CD@averesystems.com> To: deischen@freebsd.org, freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Subject: MFC of 218627 (SO_SETFIB 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: Mon, 11 Jul 2011 15:18:26 -0000 Would someone please MFC r218627 back to stable/8 and stable/7? They = are both affected. Thank you, Andrew -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-net@FreeBSD.ORG Mon Jul 11 15:50:37 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D61A106566C for ; Mon, 11 Jul 2011 15:50:37 +0000 (UTC) (envelope-from mcins1@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3544F8FC17 for ; Mon, 11 Jul 2011 15:50:36 +0000 (UTC) Received: by wwg11 with SMTP id 11so2334285wwg.1 for ; Mon, 11 Jul 2011 08:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=TKg8gBtw3Rtsq/tzRfZL6OHujhT2SH4Q7cZ0meEc4XU=; b=lnvJ5gzCKoB3qw1g1TqPAPrHV58cSdyW1D7vGdD7fMToSKXjff1S3eLV6a/gtRWc8+ VA7/kx6OQh7a1DTPUv8oNyUMmsnyQh/OwAPdAbcj5D1ULiel+EN0KBXjbNPpaHs4PYxZ HhGUmYvdmUMsotDp6qu8sKx9YVWsyiJbXfLJE= Received: by 10.216.68.200 with SMTP id l50mr4146201wed.106.1310398030203; Mon, 11 Jul 2011 08:27:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.90.67 with HTTP; Mon, 11 Jul 2011 08:26:49 -0700 (PDT) From: Matthew Cini Sarreo Date: Mon, 11 Jul 2011 17:26:49 +0200 Message-ID: To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ESP Raw Socket: Returned IP packet incorrect 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 Jul 2011 15:50:37 -0000 Hello all; I have recently encountered a problem when using raw sockets on FreeBSD 8 (8.0-RELEASE) when using ESP raw sockets. I have created a raw esp socket using: socket(AF_INET, SOCK_RAW, 50); which works fine. However, when there is a packet on the socket, recvfrom() returns a packet where the length bytes in the IP header are incorrect; they are swapped (MSB is placed in the LSB and vice-versa) tcpdump shows the following: tcpdump: listening on le0, link-type EN10MB (Ethernet), capture size 96 bytes 15:00:53.993810 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ESP (50), length 120) 10.0.251.228 > 10.0.252.231: ESP(spi=0xa0534f17,seq=0x3), length 100 0x0000: 4500 0078 0000 4000 4032 2d88 0a00 fbe4 0x0010: 0a00 fce7 a053 4f17 0000 0003 6885 8abd 0x0020: 2222 5ded 44dc 842f 3081 8fa3 bde4 2265 0x0030: 7438 2bf4 049c 664b 7dc4 44ef 1f6f 5e7d 0x0040: b8c1 482f 8c3b f488 a19a 3d9a d5fe ed9d 0x0050: b1c2 However, recvfrom() returns the following buffer: 4500 6400 0000 0040 4032 2D88 0A00 FBE4 0A00 FCE7 A053 4F17 0000 0003 6885 8ABD 2222 5DED 44DC 842F 3081 8FA3 BDE4 2265 7438 2BF4 049C 664B 7DC4 44EF 1F6F 5E7D B8C1 482F 8C3B F488 A19A 3D9A D5FE ED9D B1C2 As it is easy to see, the length is not correct (bytes 2 and 3 are 0x6400 instead of 0x0064) and it does not correspond to the value returned by recvfrom(). Is this a known issue? Am I missing some options for raw sockets that are required for FreeBSD? I have attempted this on a socket to a TUN interface (not with an ESP socket) and the buffer had the proper length; it seems to only happen with ESP. This code runs fine on multiple Linux distributions and on Windows; it was only noticed with FreeBSD. Could it be that there is some other ESP application running and interfering (I have not installed any; don't know if there are by default and I'm quite new to any of the BSDs)? Any help would be much appreciated. Matt From owner-freebsd-net@FreeBSD.ORG Mon Jul 11 16:01:45 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D780106564A for ; Mon, 11 Jul 2011 16:01:45 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id A20E48FC16 for ; Mon, 11 Jul 2011 16:01:44 +0000 (UTC) Received: from [192.168.1.195] (p508FB51C.dip.t-dialin.net [80.143.181.28]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 7757B1C0B4611; Mon, 11 Jul 2011 18:01:42 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Mon, 11 Jul 2011 18:01:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8D48DCA3-E9C5-481D-9BB4-E798942B7D34@lurchi.franken.de> References: To: Matthew Cini Sarreo X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: ESP Raw Socket: Returned IP packet incorrect 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 Jul 2011 16:01:45 -0000 On Jul 11, 2011, at 5:26 PM, Matthew Cini Sarreo wrote: > Hello all; >=20 > I have recently encountered a problem when using raw sockets on = FreeBSD 8 > (8.0-RELEASE) when using ESP raw sockets. >=20 > I have created a raw esp socket using: > socket(AF_INET, SOCK_RAW, 50); > which works fine. However, when there is a packet on the socket, = recvfrom() > returns a packet where the length bytes in the IP header are = incorrect; they > are swapped (MSB is placed in the LSB and vice-versa) >=20 > tcpdump shows the following: >=20 > tcpdump: listening on le0, link-type EN10MB (Ethernet), capture size = 96 > bytes > 15:00:53.993810 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto = ESP > (50), length 120) > 10.0.251.228 > 10.0.252.231: ESP(spi=3D0xa0534f17,seq=3D0x3), = length 100 > 0x0000: 4500 0078 0000 4000 4032 2d88 0a00 fbe4 > 0x0010: 0a00 fce7 a053 4f17 0000 0003 6885 8abd > 0x0020: 2222 5ded 44dc 842f 3081 8fa3 bde4 2265 > 0x0030: 7438 2bf4 049c 664b 7dc4 44ef 1f6f 5e7d > 0x0040: b8c1 482f 8c3b f488 a19a 3d9a d5fe ed9d > 0x0050: b1c2 >=20 >=20 > However, recvfrom() returns the following buffer: > 4500 6400 0000 0040 4032 2D88 0A00 FBE4 > 0A00 FCE7 A053 4F17 0000 0003 6885 8ABD > 2222 5DED 44DC 842F 3081 8FA3 BDE4 2265 > 7438 2BF4 049C 664B 7DC4 44EF 1F6F 5E7D > B8C1 482F 8C3B F488 A19A 3D9A D5FE ED9D > B1C2 >=20 > As it is easy to see, the length is not correct (bytes 2 and 3 are = 0x6400 > instead of 0x0064) and it does not correspond to the value returned by > recvfrom(). >=20 > Is this a known issue? Am I missing some options for raw sockets that = are > required for FreeBSD? I have attempted this on a socket to a TUN = interface > (not with an ESP socket) and the buffer had the proper length; it = seems to > only happen with ESP. This code runs fine on multiple Linux = distributions > and on Windows; it was only noticed with FreeBSD. Could it be that = there is > some other ESP application running and interfering (I have not = installed > any; don't know if there are by default and I'm quite new to any of = the > BSDs)? I think Linux provides the tot_len field in network byte order whereas FreeBSD provides it in host byte order. At least they expect it that way when using a send call. So you must take care of this in the source code of the application by using an #ifdef... Best regards Michael >=20 > Any help would be much appreciated. > Matt > _______________________________________________ > 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" >=20 From owner-freebsd-net@FreeBSD.ORG Mon Jul 11 20:47:31 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 243EE1065674; Mon, 11 Jul 2011 20:47:31 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by mx1.freebsd.org (Postfix) with ESMTP id ED3858FC15; Mon, 11 Jul 2011 20:47:30 +0000 (UTC) Received: from [10.9.200.133] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 11 Jul 2011 13:45:46 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Mon, 11 Jul 2011 13:40:24 -0700 From: "David Christensen" To: "Charles Sprickman" Date: Mon, 11 Jul 2011 13:40:36 -0700 Thread-Topic: bce packet loss Thread-Index: Acw90MNV4/35Y1XuSTeurwyr8uqmpQCN4i5g Message-ID: <5D267A3F22FD854F8F48B3D2B523819385F12FE86B@IRVEXCHCCR01.corp.ad.broadcom.com> References: <20110706201509.GA5559@michelle.cdnetworks.com> <20110707174233.GB8702@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B523819385C32D96B7@IRVEXCHCCR01.corp.ad.broadcom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6205BF703B418615257-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: YongHyeon PYUN , "freebsd-net@freebsd.org" , David Christensen Subject: RE: bce packet loss 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 Jul 2011 20:47:31 -0000 > I'm running 8.1 and at least on the bce hosts, it looks like flow > control > isn't supported, it was added on 4/30/2010: >=20 > http://svnweb.freebsd.org/base/head/sys/dev/bce/if_bce.c?r1=3D206268&r2= =3D20 > 7411 >=20 > In my 8.1 sources I still see this comment, which was removed in the > above > commit: > /* ToDo: Enable flow control support in brgphy and bge. */ This really applies to whether the user can set flow control manually. By default the NIC should auto-negotiate link speed and flow-control which is the most common case. For example,=20 you can't set RX flow control and disable TX flow control with ifconfig using the current implementation, though it is possible in Linux with ethtool. > So at least on the bce hosts (and bge it seems), I do not have flow > control available on the NIC. =20 Flow control will be set according to auto-negotiation results. For most cases that means flow control will be enabled since both sides normally support it. > The sysctl stats do show that it's > received > "XON/XOFF" frames, which I assume are flow control messages, but there's > no indication that the NIC does anything with them. There won't be any indication in the driver since flow control is managed in hardware. You'd need a wire capture to see that bce(4) has stopped sending frames in response to receiving an XOFF flow control frame or started sending frames in response to receiving an XON flow control frame. > >> We are running 8.1, am I correct in that flow control is not > implemented > >> there? We do have an 8.2-STABLE image from a month or so ago that we > >> are > >> testing with zfs v28, might that implement flow control? > > > > Flow control will depend on the NIC driver implementation. Older > > versions of the bce(4) firmware will rarely generate pause frames > > (frames would be dropped by firmware but statistics should show > > the frame drop occurring) and should always honor pause frames > > from the link partner when flow control is enabled. >=20 > I think my nics probably lack it. I am also guessing that if any > high-traffic host ignores flow control frames, that's going to screw up > other hosts as well since the one causing the buffers to fill is not > going > to throttle and the overflow will continue, correct? Flow control is asymmetric and operates independently in both directions. If the traffic source ignores flow control frames or did not auto-negotiate flow control then it can certainly overwhelm the switch or traffic sink's buffers, causing frame drop and retransmits. >=20 > >> > >> Although reading this: > >> > >> http://en.wikipedia.org/wiki/Ethernet_flow_control > >> > >> It sounds like flow control is not terribly optimal since it forces > the > >> host to block all traffic. Not sure if this means drops are > eliminated, > >> reduced or shuffled around. Frame drops should be eliminated, though congestion could spread upstream to other devices which don't have flow control and result in frame drops and retransmits there. > > When congestion is detected the switch should buffer up to a certain > > limit (say 80% of full) and then start sending pause frames to avoid > > dropping frames. This will affect all hosts connecting through the > > switch so congestion at one host can spread to other hosts (see > > > http://www.ieee802.org/3/cm_study/public/september04/thaler_3_0904.pdf). >=20 > Wow. I did not catch that. I do recall something about the flow > control > frames being multicast - so every host gets them and pauses. That's... > interesting, isn't it? Pause frames are multicast frames but they are only transmitted between link partners (NIC to switch) and never sent further in the network. Flow control is intended to be a local behavior but the link indicates it can have an unintended global effect. Dave From owner-freebsd-net@FreeBSD.ORG Tue Jul 12 04:09:47 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A380106564A for ; Tue, 12 Jul 2011 04:09:47 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 0C63E8FC12 for ; Tue, 12 Jul 2011 04:09:46 +0000 (UTC) Received: (qmail 72953 invoked by uid 0); 12 Jul 2011 04:09:45 -0000 Received: from smtp.bway.net (216.220.96.25) by xena.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Jul 2011 04:09:45 -0000 Received: (qmail 72867 invoked by uid 90); 12 Jul 2011 04:09:45 -0000 Received: from unknown (HELO ?10.3.2.40?) (spork@bway.net@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Jul 2011 04:09:45 -0000 Date: Tue, 12 Jul 2011 00:09:45 -0400 (EDT) From: Charles Sprickman X-X-Sender: spork@freemac To: David Christensen In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819385F12FE86B@IRVEXCHCCR01.corp.ad.broadcom.com> Message-ID: References: <20110706201509.GA5559@michelle.cdnetworks.com> <20110707174233.GB8702@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B523819385C32D96B7@IRVEXCHCCR01.corp.ad.broadcom.com> <5D267A3F22FD854F8F48B3D2B523819385F12FE86B@IRVEXCHCCR01.corp.ad.broadcom.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: YongHyeon PYUN , "freebsd-net@freebsd.org" , David Christensen Subject: RE: bce packet loss 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 Jul 2011 04:09:47 -0000 On Mon, 11 Jul 2011, David Christensen wrote: >> I'm running 8.1 and at least on the bce hosts, it looks like flow >> control >> isn't supported, it was added on 4/30/2010: >> >> http://svnweb.freebsd.org/base/head/sys/dev/bce/if_bce.c?r1=206268&r2=20 >> 7411 >> >> In my 8.1 sources I still see this comment, which was removed in the >> above >> commit: >> /* ToDo: Enable flow control support in brgphy and bge. */ > > This really applies to whether the user can set flow control > manually. By default the NIC should auto-negotiate link speed > and flow-control which is the most common case. For example, > you can't set RX flow control and disable TX flow control with > ifconfig using the current implementation, though it is possible > in Linux with ethtool. OK, well that explains alot. I've had it hammered into my brain over the years that for servers it's always best to set link speed and duplex manually at both ends to remove any possible issues with link negotiation. This advice was from back when FE was still new, and I recall autonegotiation causing issues, I believe specifically with some vintage Cisco switches. >> So at least on the bce hosts (and bge it seems), I do not have flow >> control available on the NIC. > > Flow control will be set according to auto-negotiation results. > For most cases that means flow control will be enabled since > both sides normally support it. It sounds like I'm causing myself trouble here by not letting everything autonegotiate. I'll move things to auto and see what happens.B >> The sysctl stats do show that it's >> received >> "XON/XOFF" frames, which I assume are flow control messages, but there's >> no indication that the NIC does anything with them. > > There won't be any indication in the driver since flow control > is managed in hardware. You'd need a wire capture to see that > bce(4) has stopped sending frames in response to receiving an > XOFF flow control frame or started sending frames in response > to receiving an XON flow control frame. Ah. I was hoping for something in the ifconfig output. I'll see if tcpdump and wireshark can tell me anything about this host. One the one host (w/bce) I just set to full auto, the switch claims to have negotiated 1000FD w/flow control (this specifically shows as "auto+enabled" on the switch side). I see that the "sysctl dev.bce.1" tree has some info, and I can see that the NIC is receiving flow control frames: dev.bce.1.stat_XonPauseFramesReceived: 16638 dev.bce.1.stat_XoffPauseFramesReceived: 17239 These lines are a bit puzzling though: dev.bce.1.stat_FlowControlDone: 0 dev.bce.1.stat_XoffStateEntered: 0 >>>> We are running 8.1, am I correct in that flow control is not >> implemented >>>> there? We do have an 8.2-STABLE image from a month or so ago that we >>>> are >>>> testing with zfs v28, might that implement flow control? >>> >>> Flow control will depend on the NIC driver implementation. Older >>> versions of the bce(4) firmware will rarely generate pause frames >>> (frames would be dropped by firmware but statistics should show >>> the frame drop occurring) and should always honor pause frames >>> from the link partner when flow control is enabled. >> >> I think my nics probably lack it. I am also guessing that if any >> high-traffic host ignores flow control frames, that's going to screw up >> other hosts as well since the one causing the buffers to fill is not >> going >> to throttle and the overflow will continue, correct? > > Flow control is asymmetric and operates independently in both > directions. If the traffic source ignores flow control frames > or did not auto-negotiate flow control then it can certainly > overwhelm the switch or traffic sink's buffers, causing frame > drop and retransmits. I ran a quick scp of a large file to another host with 100Mb connectivity and those xon/xoff counters incremented, but they were doing that previously. I assume that confirms the switch is at least asking for a pause. I still saw about 5000 dropped ingress packets on the switch, but I assume that could be due to some other host filling the buffers. >> >>>> >>>> Although reading this: >>>> >>>> http://en.wikipedia.org/wiki/Ethernet_flow_control >>>> >>>> It sounds like flow control is not terribly optimal since it forces >> the >>>> host to block all traffic. Not sure if this means drops are >> eliminated, >>>> reduced or shuffled around. > > Frame drops should be eliminated, though congestion could > spread upstream to other devices which don't have flow control > and result in frame drops and retransmits there. > >>> When congestion is detected the switch should buffer up to a certain >>> limit (say 80% of full) and then start sending pause frames to avoid >>> dropping frames. This will affect all hosts connecting through the >>> switch so congestion at one host can spread to other hosts (see >>> >> http://www.ieee802.org/3/cm_study/public/september04/thaler_3_0904.pdf). >> >> Wow. I did not catch that. I do recall something about the flow >> control >> frames being multicast - so every host gets them and pauses. That's... >> interesting, isn't it? > > Pause frames are multicast frames but they are only transmitted > between link partners (NIC to switch) and never sent further in > the network. Flow control is intended to be a local behavior but > the link indicates it can have an unintended global effect. Interesting. Thanks very much for the information on auto-negotiation - it was totally unclear to me that I'd basically been disabling flow control by manuallying configuring the interface. Thanks, Charles > Dave > > From owner-freebsd-net@FreeBSD.ORG Tue Jul 12 05:36:00 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id CBF46106564A; Tue, 12 Jul 2011 05:36:00 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 4658D1503BA; Tue, 12 Jul 2011 05:36:00 +0000 (UTC) Message-ID: <4E1BDD3F.4090607@FreeBSD.org> Date: Mon, 11 Jul 2011 22:35:59 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: Charles Sprickman References: <20110706201509.GA5559@michelle.cdnetworks.com> <20110707174233.GB8702@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B523819385C32D96B7@IRVEXCHCCR01.corp.ad.broadcom.com> <5D267A3F22FD854F8F48B3D2B523819385F12FE86B@IRVEXCHCCR01.corp.ad.broadcom.com> In-Reply-To: X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: YongHyeon PYUN , "freebsd-net@freebsd.org" , David Christensen , David Christensen Subject: Re: bce packet loss 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 Jul 2011 05:36:00 -0000 On 07/11/2011 21:09, Charles Sprickman wrote: > I've had it hammered into my brain over the years that for servers it's > always best to set link speed and duplex manually at both ends to remove > any possible issues with link negotiation. That hasn't been the right thing to do for at least 8 years or so, probably 10 or more. Yes, back in the 90's when all of this stuff was still new it was not uncommon to have autonegotiation issues, but any even sort of modern hardware (on either side of the link) will do better with auto than not. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Tue Jul 12 05:47:58 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BD7A1065674 for ; Tue, 12 Jul 2011 05:47:58 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 2B6A18FC19 for ; Tue, 12 Jul 2011 05:47:57 +0000 (UTC) Received: (qmail 43063 invoked by uid 0); 12 Jul 2011 05:47:57 -0000 Received: from smtp.bway.net (216.220.96.25) by xena.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Jul 2011 05:47:57 -0000 Received: (qmail 43046 invoked by uid 90); 12 Jul 2011 05:47:57 -0000 Received: from unknown (HELO ?10.3.2.40?) (spork@bway.net@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Jul 2011 05:47:57 -0000 Date: Tue, 12 Jul 2011 01:47:55 -0400 (EDT) From: Charles Sprickman X-X-Sender: spork@freemac To: Doug Barton In-Reply-To: <4E1BDD3F.4090607@FreeBSD.org> Message-ID: References: <20110706201509.GA5559@michelle.cdnetworks.com> <20110707174233.GB8702@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B523819385C32D96B7@IRVEXCHCCR01.corp.ad.broadcom.com> <5D267A3F22FD854F8F48B3D2B523819385F12FE86B@IRVEXCHCCR01.corp.ad.broadcom.com> <4E1BDD3F.4090607@FreeBSD.org> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: YongHyeon PYUN , "freebsd-net@freebsd.org" , David Christensen , David Christensen Subject: Re: bce packet loss 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 Jul 2011 05:47:58 -0000 On Mon, 11 Jul 2011, Doug Barton wrote: > On 07/11/2011 21:09, Charles Sprickman wrote: >> I've had it hammered into my brain over the years that for servers it's >> always best to set link speed and duplex manually at both ends to remove >> any possible issues with link negotiation. > > That hasn't been the right thing to do for at least 8 years or so, > probably 10 or more. > > Yes, back in the 90's when all of this stuff was still new it was not > uncommon to have autonegotiation issues, but any even sort of modern > hardware (on either side of the link) will do better with auto than not. Some of us still work at places where the hardware is 10 years old, you know. :) I do still see fixed setups in service provider handoffs - for example this colo, Level3 and Hurricane. Also all our metro ethernet stuff specifies a fixed configuration. >From what I can gather, this seems to be the standard practice in that space, but then again you're supposed to be plugging into equipment that wouldn't have the buffer issues that a $450 Dell switch would have. The rule I recall is never do autoneg on one side and fixed on the other, that more often than not will end up in a duplex mismatch. Charles > > hth, > > Doug > > -- > > Nothin' ever doesn't change, but nothin' changes much. > -- OK Go > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ > > From owner-freebsd-net@FreeBSD.ORG Tue Jul 12 05:52:42 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id B68FD1065673; Tue, 12 Jul 2011 05:52:42 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 6F9C817A37E; Tue, 12 Jul 2011 05:52:40 +0000 (UTC) Message-ID: <4E1BE127.9060200@FreeBSD.org> Date: Mon, 11 Jul 2011 22:52:39 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: Charles Sprickman References: <20110706201509.GA5559@michelle.cdnetworks.com> <20110707174233.GB8702@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B523819385C32D96B7@IRVEXCHCCR01.corp.ad.broadcom.com> <5D267A3F22FD854F8F48B3D2B523819385F12FE86B@IRVEXCHCCR01.corp.ad.broadcom.com> <4E1BDD3F.4090607@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: YongHyeon PYUN , "freebsd-net@freebsd.org" , David Christensen , David Christensen Subject: Re: bce packet loss 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 Jul 2011 05:52:42 -0000 On 07/11/2011 22:47, Charles Sprickman wrote: > On Mon, 11 Jul 2011, Doug Barton wrote: > >> On 07/11/2011 21:09, Charles Sprickman wrote: >>> I've had it hammered into my brain over the years that for servers it's >>> always best to set link speed and duplex manually at both ends to remove >>> any possible issues with link negotiation. >> >> That hasn't been the right thing to do for at least 8 years or so, >> probably 10 or more. >> >> Yes, back in the 90's when all of this stuff was still new it was not >> uncommon to have autonegotiation issues, but any even sort of modern >> hardware (on either side of the link) will do better with auto than not. > > Some of us still work at places where the hardware is 10 years old, you > know. :) True ... hence my careful specification of "sort of modern." :) > I do still see fixed setups in service provider handoffs - for example > this colo, Level3 and Hurricane. Also all our metro ethernet stuff > specifies a fixed configuration. > > From what I can gather, this seems to be the standard practice in that > space, but then again you're supposed to be plugging into equipment that > wouldn't have the buffer issues that a $450 Dell switch would have. Well one could also say that this sort of thing tends to result from the, "There is a knob, I MUST twist it!" syndrome. > The rule I recall is never do autoneg on one side and fixed on the > other, that more often than not will end up in a duplex mismatch. Yes, that's definitely true, and I should have mentioned it. Whatever you do on one side (auto/manual) you must also do on the other. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Tue Jul 12 07:10:57 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EBFA106564A for ; Tue, 12 Jul 2011 07:10:57 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id B7C7C8FC0A for ; Tue, 12 Jul 2011 07:10:56 +0000 (UTC) Received: (qmail 79805 invoked from network); 12 Jul 2011 06:09:31 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 Jul 2011 06:09:31 -0000 Message-ID: <4E1BF37F.3000705@freebsd.org> Date: Tue, 12 Jul 2011 09:10:55 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Andrew Boyer References: <867h7zxvd2.fsf@kopusha.home.net> <4E158EB3.80203@freebsd.org> <86iprd99mi.fsf@kopusha.home.net> <4E16E136.7030509@freebsd.org> <1C53806A-9BA1-4626-BA1D-2D1922E30372@averesystems.com> In-Reply-To: <1C53806A-9BA1-4626-BA1D-2D1922E30372@averesystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Mikolaj Golub Subject: Re: MFC Re: soreceive_stream: issues with O_NONBLOCK 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 Jul 2011 07:10:57 -0000 On 11.07.2011 17:15, Andrew Boyer wrote: > On Jul 8, 2011, at 6:51 AM, Andre Oppermann wrote: > >> On 07.07.2011 21:24, Mikolaj Golub wrote: >>> >>> On Thu, 07 Jul 2011 12:47:15 +0200 Andre Oppermann wrote: >>> >>> AO> Please try this patch: AO> >>> http://people.freebsd.org/~andre/soreceive_stream.diff-20110707 >>> >>> It works for me. No issues detected so far. Thanks. >> >> Committed in r223863. Many thanks for testing! >> >> -- Andre > > Hello Andre, It appears that r197236 was never MFC'd, so soreceive_stream is still on by default > in stable/8. Would you be able to MFC it along with 223839 and 223863? soreceive_stream() was never on by default. In fact one had to compile it in and enable it with a tuneable. I plan do the MFC's in a few days. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Jul 12 09:23:33 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17F4D106564A for ; Tue, 12 Jul 2011 09:23:33 +0000 (UTC) (envelope-from mcins1@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 90BCA8FC12 for ; Tue, 12 Jul 2011 09:23:32 +0000 (UTC) Received: by wwe6 with SMTP id 6so4452652wwe.31 for ; Tue, 12 Jul 2011 02:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3iRJVv0ZvOvmuOySgF4DTkHtJd0zF6XTvJ+lQEfaeoo=; b=HnK8csD8esf/FXad0w+d0rYKLyHnYVY1yRMt7Eo6MNnLtE9SUewjhvqC6/TPx/+tk/ C7Ogz0BcEgzDW+Eu0G+3H6UzCBHwf7p7Jw1d4lLgqc0Ww0WaG6dBnQ2KHuETYRzyqUVf DQOZR1kVmZKlX3Iet4jrAcJb3Hl5dzhEZXgn4= Received: by 10.216.141.155 with SMTP id g27mr2174424wej.76.1310462611217; Tue, 12 Jul 2011 02:23:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.90.67 with HTTP; Tue, 12 Jul 2011 02:23:11 -0700 (PDT) In-Reply-To: <8D48DCA3-E9C5-481D-9BB4-E798942B7D34@lurchi.franken.de> References: <8D48DCA3-E9C5-481D-9BB4-E798942B7D34@lurchi.franken.de> From: Matthew Cini Sarreo Date: Tue, 12 Jul 2011 11:23:11 +0200 Message-ID: To: =?ISO-8859-1?Q?Michael_T=FCxen?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: ESP Raw Socket: Returned IP packet incorrect 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 Jul 2011 09:23:33 -0000 Thanks for your reply. Where can I find documentation about this? (Or would it be possible for you to direct me at the proper sources?) Thanks & Regards Matt On 11 July 2011 18:01, Michael T=FCxen wr= ote: > On Jul 11, 2011, at 5:26 PM, Matthew Cini Sarreo wrote: > > > Hello all; > > > > I have recently encountered a problem when using raw sockets on FreeBSD= 8 > > (8.0-RELEASE) when using ESP raw sockets. > > > > I have created a raw esp socket using: > > socket(AF_INET, SOCK_RAW, 50); > > which works fine. However, when there is a packet on the socket, > recvfrom() > > returns a packet where the length bytes in the IP header are incorrect; > they > > are swapped (MSB is placed in the LSB and vice-versa) > > > > tcpdump shows the following: > > > > tcpdump: listening on le0, link-type EN10MB (Ethernet), capture size 96 > > bytes > > 15:00:53.993810 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto > ESP > > (50), length 120) > > 10.0.251.228 > 10.0.252.231: ESP(spi=3D0xa0534f17,seq=3D0x3), length= 100 > > 0x0000: 4500 0078 0000 4000 4032 2d88 0a00 fbe4 > > 0x0010: 0a00 fce7 a053 4f17 0000 0003 6885 8abd > > 0x0020: 2222 5ded 44dc 842f 3081 8fa3 bde4 2265 > > 0x0030: 7438 2bf4 049c 664b 7dc4 44ef 1f6f 5e7d > > 0x0040: b8c1 482f 8c3b f488 a19a 3d9a d5fe ed9d > > 0x0050: b1c2 > > > > > > However, recvfrom() returns the following buffer: > > 4500 6400 0000 0040 4032 2D88 0A00 FBE4 > > 0A00 FCE7 A053 4F17 0000 0003 6885 8ABD > > 2222 5DED 44DC 842F 3081 8FA3 BDE4 2265 > > 7438 2BF4 049C 664B 7DC4 44EF 1F6F 5E7D > > B8C1 482F 8C3B F488 A19A 3D9A D5FE ED9D > > B1C2 > > > > As it is easy to see, the length is not correct (bytes 2 and 3 are 0x64= 00 > > instead of 0x0064) and it does not correspond to the value returned by > > recvfrom(). > > > > Is this a known issue? Am I missing some options for raw sockets that a= re > > required for FreeBSD? I have attempted this on a socket to a TUN > interface > > (not with an ESP socket) and the buffer had the proper length; it seems > to > > only happen with ESP. This code runs fine on multiple Linux distributio= ns > > and on Windows; it was only noticed with FreeBSD. Could it be that ther= e > is > > some other ESP application running and interfering (I have not installe= d > > any; don't know if there are by default and I'm quite new to any of the > > BSDs)? > I think Linux provides the tot_len field in network byte order whereas > FreeBSD provides it in host byte order. At least they expect it that way > when using a send call. > > So you must take care of this in the source code of the application by > using an #ifdef... > > Best regards > Michael > > > > Any help would be much appreciated. > > Matt > > _______________________________________________ > > 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 Jul 12 10:25:42 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F52D106564A for ; Tue, 12 Jul 2011 10:25:42 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id 557558FC08 for ; Tue, 12 Jul 2011 10:25:41 +0000 (UTC) Received: from [192.168.1.195] (p508FB51C.dip.t-dialin.net [80.143.181.28]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 3CD571C0C0BE9; Tue, 12 Jul 2011 12:25:39 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Tue, 12 Jul 2011 12:25:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0EDA11E4-A79C-4D62-8782-E1566573D138@lurchi.franken.de> References: <8D48DCA3-E9C5-481D-9BB4-E798942B7D34@lurchi.franken.de> To: Matthew Cini Sarreo X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: ESP Raw Socket: Returned IP packet incorrect 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 Jul 2011 10:25:42 -0000 On Jul 12, 2011, at 11:23 AM, Matthew Cini Sarreo wrote: > Thanks for your reply. Where can I find documentation about this? (Or = would it be possible for you to direct me at the proper sources?) At http://fxr.watson.org/fxr/source/netinet/ip_input.c#L464 the length field is converted to host byte order. I have not looked at the Linux sources. I figured it out when writing an SCTP test tool which uses raw socket IO and support Solaris, Linux, FreeBSD and Mac OS X. Best regards Michael >=20 > Thanks & Regards > Matt >=20 > On 11 July 2011 18:01, Michael T=FCxen = wrote: > On Jul 11, 2011, at 5:26 PM, Matthew Cini Sarreo wrote: >=20 > > Hello all; > > > > I have recently encountered a problem when using raw sockets on = FreeBSD 8 > > (8.0-RELEASE) when using ESP raw sockets. > > > > I have created a raw esp socket using: > > socket(AF_INET, SOCK_RAW, 50); > > which works fine. However, when there is a packet on the socket, = recvfrom() > > returns a packet where the length bytes in the IP header are = incorrect; they > > are swapped (MSB is placed in the LSB and vice-versa) > > > > tcpdump shows the following: > > > > tcpdump: listening on le0, link-type EN10MB (Ethernet), capture size = 96 > > bytes > > 15:00:53.993810 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], = proto ESP > > (50), length 120) > > 10.0.251.228 > 10.0.252.231: ESP(spi=3D0xa0534f17,seq=3D0x3), = length 100 > > 0x0000: 4500 0078 0000 4000 4032 2d88 0a00 fbe4 > > 0x0010: 0a00 fce7 a053 4f17 0000 0003 6885 8abd > > 0x0020: 2222 5ded 44dc 842f 3081 8fa3 bde4 2265 > > 0x0030: 7438 2bf4 049c 664b 7dc4 44ef 1f6f 5e7d > > 0x0040: b8c1 482f 8c3b f488 a19a 3d9a d5fe ed9d > > 0x0050: b1c2 > > > > > > However, recvfrom() returns the following buffer: > > 4500 6400 0000 0040 4032 2D88 0A00 FBE4 > > 0A00 FCE7 A053 4F17 0000 0003 6885 8ABD > > 2222 5DED 44DC 842F 3081 8FA3 BDE4 2265 > > 7438 2BF4 049C 664B 7DC4 44EF 1F6F 5E7D > > B8C1 482F 8C3B F488 A19A 3D9A D5FE ED9D > > B1C2 > > > > As it is easy to see, the length is not correct (bytes 2 and 3 are = 0x6400 > > instead of 0x0064) and it does not correspond to the value returned = by > > recvfrom(). > > > > Is this a known issue? Am I missing some options for raw sockets = that are > > required for FreeBSD? I have attempted this on a socket to a TUN = interface > > (not with an ESP socket) and the buffer had the proper length; it = seems to > > only happen with ESP. This code runs fine on multiple Linux = distributions > > and on Windows; it was only noticed with FreeBSD. Could it be that = there is > > some other ESP application running and interfering (I have not = installed > > any; don't know if there are by default and I'm quite new to any of = the > > BSDs)? > I think Linux provides the tot_len field in network byte order whereas > FreeBSD provides it in host byte order. At least they expect it that = way > when using a send call. >=20 > So you must take care of this in the source code of the application by > using an #ifdef... >=20 > Best regards > Michael > > > > Any help would be much appreciated. > > Matt > > _______________________________________________ > > 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" > > >=20 >=20 From owner-freebsd-net@FreeBSD.ORG Tue Jul 12 14:30:06 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC1921065674; Tue, 12 Jul 2011 14:30:06 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-245-Pennsylvania.hfc.comcastbusiness.net [75.149.8.245]) by mx1.freebsd.org (Postfix) with ESMTP id 9F08D8FC0A; Tue, 12 Jul 2011 14:30:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id D8ABB8BC01F; Tue, 12 Jul 2011 10:32:27 -0400 (EDT) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nh00HAyPPpgS; Tue, 12 Jul 2011 10:32:25 -0400 (EDT) Received: from riven.arriad.com (fw.arriad.com [10.0.0.16]) by zimbra.averesystems.com (Postfix) with ESMTPSA id E54018BC003; Tue, 12 Jul 2011 10:32:24 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Andrew Boyer In-Reply-To: <4E1BF37F.3000705@freebsd.org> Date: Tue, 12 Jul 2011 10:30:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8CEFCFEB-8052-4ADE-AE6B-533F43C76409@averesystems.com> References: <867h7zxvd2.fsf@kopusha.home.net> <4E158EB3.80203@freebsd.org> <86iprd99mi.fsf@kopusha.home.net> <4E16E136.7030509@freebsd.org> <1C53806A-9BA1-4626-BA1D-2D1922E30372@averesystems.com> <4E1BF37F.3000705@freebsd.org> To: Andre Oppermann X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org, Mikolaj Golub Subject: Re: MFC Re: soreceive_stream: issues with O_NONBLOCK 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 Jul 2011 14:30:07 -0000 On Jul 12, 2011, at 3:10 AM, Andre Oppermann wrote: > On 11.07.2011 17:15, Andrew Boyer wrote: >> On Jul 8, 2011, at 6:51 AM, Andre Oppermann wrote: >>=20 >>> On 07.07.2011 21:24, Mikolaj Golub wrote: >>>>=20 >>>> On Thu, 07 Jul 2011 12:47:15 +0200 Andre Oppermann wrote: >>>>=20 >>>> AO> Please try this patch: AO> >>>> http://people.freebsd.org/~andre/soreceive_stream.diff-20110707 >>>>=20 >>>> It works for me. No issues detected so far. Thanks. >>>=20 >>> Committed in r223863. Many thanks for testing! >>>=20 >>> -- Andre >>=20 >> Hello Andre, It appears that r197236 was never MFC'd, so = soreceive_stream is still on by default >> in stable/8. Would you be able to MFC it along with 223839 and = 223863? >=20 > soreceive_stream() was never on by default. In fact one had to compile = it in > and enable it with a tuneable. >=20 > I plan do the MFC's in a few days. >=20 > --=20 > Andre My bad, I missed the #if 0's in tcp_usrreq.c. Looking forward to the = MFC's to try it out. -Andrew -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-net@FreeBSD.ORG Tue Jul 12 15:17:01 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D0ED106564A for ; Tue, 12 Jul 2011 15:17:01 +0000 (UTC) (envelope-from westr@connection.ca) Received: from nc-tor-mail2.connection.ca (nc-tor-mail2.connection.ca [205.207.122.27]) by mx1.freebsd.org (Postfix) with ESMTP id 5430F8FC0C for ; Tue, 12 Jul 2011 15:17:01 +0000 (UTC) Received: from westrspeedy (external.tor.connection.ca [216.234.38.18]) by nc-tor-mail2.connection.ca (Postfix) with ESMTP id 9290274E55A for ; Tue, 12 Jul 2011 11:02:13 -0400 (EDT) From: "Ross West" To: References: <20110706201509.GA5559@michelle.cdnetworks.com> <20110707174233.GB8702@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B523819385C32D96B7@IRVEXCHCCR01.corp.ad.broadcom.com> <5D267A3F22FD854F8F48B3D2B523819385F12FE86B@IRVEXCHCCR01.corp.ad.broadcom.com> <4E1BDD3F.4090607@FreeBSD.org> <4E1BE127.9060200@FreeBSD.org> In-Reply-To: <4E1BE127.9060200@FreeBSD.org> Date: Tue, 12 Jul 2011 11:02:18 -0400 Organization: Network Connection Message-ID: <000b01cc40a4$b17300a0$145901e0$@connection.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDjKMUNQ89AZue+Aaeiuq9+R+IBHwGyC11LAe6TTTkCAha1FQIoEth9Anmp/xMBEWPh0gKZjoSPAVt9qHYBiTfMRgDSHzniAUusmRCWI2YpEA== Content-Language: en-us Subject: RE: bce packet loss 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 Jul 2011 15:17:01 -0000 > > I do still see fixed setups in service provider handoffs - for example > > this colo, Level3 and Hurricane. Also all our metro ethernet stuff > > specifies a fixed configuration. > > Well one could also say that this sort of thing tends to result from > the, "There is a knob, I MUST twist it!" syndrome. It's a layer 8-9 issue. It results from an auto-negotiation giving a half-duplex connection, and no one noticing until 6 months down the road, then demanding a huge credit from the provider for not selling a full-duplex circuit as was contracted. This happens way more often that you'd think. R. From owner-freebsd-net@FreeBSD.ORG Tue Jul 12 18:54:55 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D195A106566C for ; Tue, 12 Jul 2011 18:54:55 +0000 (UTC) (envelope-from fazaeli@sepehrs.com) Received: from sepehrs.com (mail2.sepehrs.com [213.217.59.98]) by mx1.freebsd.org (Postfix) with ESMTP id 1C3538FC0A for ; Tue, 12 Jul 2011 18:54:54 +0000 (UTC) Received: from [127.0.0.1] ([192.168.3.10]) by sepehrs.com (8.14.3/8.14.3) with ESMTP id p6CIoibH020250; Tue, 12 Jul 2011 23:20:45 +0430 (IRDT) Message-ID: <4E1C9870.1070500@sepehrs.com> Date: Tue, 12 Jul 2011 23:24:40 +0430 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Mike Tancsa References: <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> <1296597827.2326.12.camel@hitfishpass-lx.corp.yahoo.com> <4D48C973.7080503@sentex.net> <4D49A26B.5050803@sentex.net> <1296842996.2233.0.camel@hitfishpass-lx.corp.yahoo.com> <4D4F3497.6050505@sentex.net> <4E141D01.3040203@sepehrs.com> <4E1438B8.9000409@sentex.net> In-Reply-To: <4E1438B8.9000409@sentex.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" Subject: Re: em driver, 82574L chip, and possibly ASPM 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 Jul 2011 18:54:55 -0000 tanx. out of curiosity, can some one pls. explain this? In if_em.c, function em_start_locked, there is: if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD) em_txeof(txr); inside while loop. While is if_igb.c, function igb_start_locked, a similar code it is out of while loop: if (txr->tx_avail <= IGB_TX_CLEANUP_THRESHOLD) igb_txeof(txr); is this intentional or mistake? On 7/6/2011 2:58 PM, Mike Tancsa wrote: > On 7/6/2011 4:29 AM, Hooman Fazaeli wrote: >> Can you pls. share the patch for freebsd 7? > Its in the tree. > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/e1000/ > > > ---Mike > From owner-freebsd-net@FreeBSD.ORG Tue Jul 12 18:58:26 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E3C71065673 for ; Tue, 12 Jul 2011 18:58:26 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 218478FC18 for ; Tue, 12 Jul 2011 18:58:26 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p6CIwKpf025700; Tue, 12 Jul 2011 14:58:21 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4E1C996B.8000205@sentex.net> Date: Tue, 12 Jul 2011 14:58:51 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Hooman Fazaeli References: <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> <1296597827.2326.12.camel@hitfishpass-lx.corp.yahoo.com> <4D48C973.7080503@sentex.net> <4D49A26B.5050803@sentex.net> <1296842996.2233.0.camel@hitfishpass-lx.corp.yahoo.com> <4D4F3497.6050505@sentex.net> <4E141D01.3040203@sepehrs.com> <4E1438B8.9000409@sentex.net> <4E1C9870.1070500@sepehrs.com> In-Reply-To: <4E1C9870.1070500@sepehrs.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: "freebsd-net@freebsd.org" , Jack Vogel Subject: Re: em driver, 82574L chip, and possibly ASPM 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 Jul 2011 18:58:26 -0000 On 7/12/2011 2:54 PM, Hooman Fazaeli wrote: > tanx. > > out of curiosity, can some one pls. explain this? > > In if_em.c, function em_start_locked, there is: > > if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD) > em_txeof(txr); > > inside while loop. While is if_igb.c, function igb_start_locked, > a similar code it is out of while loop: > > if (txr->tx_avail <= IGB_TX_CLEANUP_THRESHOLD) > igb_txeof(txr); > > is this intentional or mistake? > No idea, but Jack Vogel might know. ---Mike > > On 7/6/2011 2:58 PM, Mike Tancsa wrote: >> On 7/6/2011 4:29 AM, Hooman Fazaeli wrote: >>> Can you pls. share the patch for freebsd 7? >> Its in the tree. >> >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/e1000/ >> >> >> ---Mike >> > > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Tue Jul 12 19:03:58 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BF611065670; Tue, 12 Jul 2011 19:03:58 +0000 (UTC) (envelope-from fazaeli@sepehrs.com) Received: from sepehrs.com (sepehrs.com [213.217.59.98]) by mx1.freebsd.org (Postfix) with ESMTP id CF9A78FC16; Tue, 12 Jul 2011 19:03:56 +0000 (UTC) Received: from [127.0.0.1] ([192.168.3.10]) by sepehrs.com (8.14.3/8.14.3) with ESMTP id p6CIxeUd053407; Tue, 12 Jul 2011 23:29:40 +0430 (IRDT) Message-ID: <4E1C9A88.5080102@sepehrs.com> Date: Tue, 12 Jul 2011 23:33:36 +0430 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Mike Tancsa References: <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> <1296597827.2326.12.camel@hitfishpass-lx.corp.yahoo.com> <4D48C973.7080503@sentex.net> <4D49A26B.5050803@sentex.net> <1296842996.2233.0.camel@hitfishpass-lx.corp.yahoo.com> <4D4F3497.6050505@sentex.net> In-Reply-To: <4D4F3497.6050505@sentex.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , Jan Koum , Ivan Voras , "freebsd-hardware@freebsd.org" , Sean Bruno , Jack Vogel Subject: Re: em driver, 82574L chip, and possibly ASPM 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 Jul 2011 19:03:58 -0000 I have similar problems on a couple of 7.3 boxes with latest driver form -CURRENT. I just wanted to know if your 7 boxes work fine so I look for cause else where. On 2/7/2011 3:23 AM, Mike Tancsa wrote: > So far so good. I would often get a hang on the level zero dumps to my > backup server Sunday AM, and it made it through! So a good sign, but > not a definitive sign. > > I have a PCIe em card that has this chipset as well and was showing the > same sort of problem in a customer's RELENG_7 box. I will see if I can > get the customer to try the card in their box with the patch for > RELENG_7 as it would show this issue at least once a day until I pulled > the card for an older version > > ---Mike > > > On 2/4/2011 1:12 PM, Jack Vogel wrote: >> Was curious too, but being more patient than you :) >> >> Jack >> >> >> On Fri, Feb 4, 2011 at 10:09 AM, Sean Bruno wrote: >> >>> Any more data on this problem or do we have to wait a while? >>> >>> Sean >>> >>> >>> On Wed, 2011-02-02 at 10:28 -0800, Mike Tancsa wrote: >>>> On 2/2/2011 12:37 PM, Jack Vogel wrote: >>>>> So has everyone that wanted to get something testing been able to do >>> so? >>>> I have been testing in the back and will deploy to my production box >>>> this afternoon. As I am not able to reproduce it easily, it will be a >>>> bit before I can say the issue is gone. Jan however, was able to >>>> trigger it with greater ease ? >>>> >>>> ---Mike >>>> >>>>> Jack >>>>> >>>>> >>>>> On Tue, Feb 1, 2011 at 7:03 PM, Mike Tancsa wrote: >>>>> >>>>>> On 2/1/2011 5:03 PM, Sean Bruno wrote: >>>>>>> On Tue, 2011-02-01 at 13:43 -0800, Jack Vogel wrote: >>>>>>>> To those who are going to test, here is the if_em.c, based on head, >>>>>>>> with my >>>>>>>> changes, I have to leave for the afternoon, and have not had a >>> chance >>>>>>>> to build >>>>>>>> this, but it should work. I will check back in the later evening. >>>>>>>> >>>>>>>> Any blatant problems Sean, feel free to fix them :) >>>>>>>> >>>>>>>> Jack >>>>>>>> >>>>>>> >>>>>>> I suspect that line 1490 should be: >>>>>>> if (more_rx || (ifp->if_drv_flags& IFF_DRV_OACTIVE)) { >>>>>>> >>>>>> >>>>>> I have hacked up a RELENG_8 version which I think is correct including >>>>>> the above change >>>>>> >>>>>> http://www.tancsa.com/if_em-8.c >>>>>> >>>>>> >>>>>> >>>>>> --- if_em.c.orig 2011-02-01 21:47:14.000000000 -0500 >>>>>> +++ if_em.c 2011-02-01 21:47:19.000000000 -0500 >>>>>> @@ -30,7 +30,7 @@ >>>>>> POSSIBILITY OF SUCH DAMAGE. >>>>>> >>>>>> >>>>>> >>> ******************************************************************************/ >>>>>> -/*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.20 2011/01/22 01:37:53 >>>>>> jfv Exp $*/ >>>>>> +/*$FreeBSD$*/ >>>>>> >>>>>> #ifdef HAVE_KERNEL_OPTION_HEADERS >>>>>> #include "opt_device_polling.h" >>>>>> @@ -93,7 +93,7 @@ >>>>>> >>> /********************************************************************* >>>>>> * Driver version: >>>>>> >>> *********************************************************************/ >>>>>> -char em_driver_version[] = "7.1.9"; >>>>>> +char em_driver_version[] = "7.1.9-test"; >>>>>> >>>>>> >>> /********************************************************************* >>>>>> * PCI Device ID Table >>>>>> @@ -927,11 +927,10 @@ >>>>>> if (!adapter->link_active) >>>>>> return; >>>>>> >>>>>> - /* Call cleanup if number of TX descriptors low */ >>>>>> - if (txr->tx_avail<= EM_TX_CLEANUP_THRESHOLD) >>>>>> - em_txeof(txr); >>>>>> - >>>>>> while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { >>>>>> + /* First cleanup if TX descriptors low */ >>>>>> + if (txr->tx_avail<= EM_TX_CLEANUP_THRESHOLD) >>>>>> + em_txeof(txr); >>>>>> if (txr->tx_avail< EM_MAX_SCATTER) { >>>>>> ifp->if_drv_flags |= IFF_DRV_OACTIVE; >>>>>> break; >>>>>> @@ -1411,8 +1410,7 @@ >>>>>> if (!drbr_empty(ifp, txr->br)) >>>>>> em_mq_start_locked(ifp, txr, NULL); >>>>>> #else >>>>>> - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) >>>>>> - em_start_locked(ifp, txr); >>>>>> + em_start_locked(ifp, txr); >>>>>> #endif >>>>>> EM_TX_UNLOCK(txr); >>>>>> >>>>>> @@ -1475,11 +1473,10 @@ >>>>>> struct ifnet *ifp = adapter->ifp; >>>>>> struct tx_ring *txr = adapter->tx_rings; >>>>>> struct rx_ring *rxr = adapter->rx_rings; >>>>>> - bool more; >>>>>> - >>>>>> >>>>>> if (ifp->if_drv_flags& IFF_DRV_RUNNING) { >>>>>> - more = em_rxeof(rxr, adapter->rx_process_limit, NULL); >>>>>> + bool more_rx; >>>>>> + more_rx = em_rxeof(rxr, adapter->rx_process_limit, >>> NULL); >>>>>> EM_TX_LOCK(txr); >>>>>> em_txeof(txr); >>>>>> @@ -1487,12 +1484,10 @@ >>>>>> if (!drbr_empty(ifp, txr->br)) >>>>>> em_mq_start_locked(ifp, txr, NULL); >>>>>> #else >>>>>> - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) >>>>>> - em_start_locked(ifp, txr); >>>>>> + em_start_locked(ifp, txr); >>>>>> #endif >>>>>> - em_txeof(txr); >>>>>> EM_TX_UNLOCK(txr); >>>>>> - if (more) { >>>>>> + if (more_rx || (ifp->if_drv_flags& IFF_DRV_OACTIVE)) >>> { >>>>>> taskqueue_enqueue(adapter->tq, >>> &adapter->que_task); >>>>>> return; >>>>>> } >>>>>> @@ -1604,7 +1599,6 @@ >>>>>> if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) >>>>>> em_start_locked(ifp, txr); >>>>>> #endif >>>>>> - em_txeof(txr); >>>>>> E1000_WRITE_REG(&adapter->hw, E1000_IMS, txr->ims); >>>>>> EM_TX_UNLOCK(txr); >>>>>> } >>>>>> @@ -3730,17 +3724,17 @@ >>>>>> txr->queue_status = EM_QUEUE_HUNG; >>>>>> >>>>>> /* >>>>>> - * If we have enough room, clear IFF_DRV_OACTIVE >>>>>> + * If we have a minimum free, clear IFF_DRV_OACTIVE >>>>>> * to tell the stack that it is OK to send packets. >>>>>> */ >>>>>> - if (txr->tx_avail> EM_TX_CLEANUP_THRESHOLD) { >>>>>> + if (txr->tx_avail> EM_MAX_SCATTER) >>>>>> ifp->if_drv_flags&= ~IFF_DRV_OACTIVE; >>>>>> - /* Disable watchdog if all clean */ >>>>>> - if (txr->tx_avail == adapter->num_tx_desc) { >>>>>> - txr->queue_status = EM_QUEUE_IDLE; >>>>>> - return (FALSE); >>>>>> - } >>>>>> - } >>>>>> + >>>>>> + /* Disable watchdog if all clean */ >>>>>> + if (txr->tx_avail == adapter->num_tx_desc) { >>>>>> + txr->queue_status = EM_QUEUE_IDLE; >>>>>> + return (FALSE); >>>>>> + } >>>>>> >>>>>> return (TRUE); >>>>>> } >>>>>> @@ -5064,8 +5058,8 @@ >>>>>> char namebuf[QUEUE_NAME_LEN]; >>>>>> >>>>>> /* Driver Statistics */ >>>>>> - SYSCTL_ADD_UINT(ctx, child, OID_AUTO, "link_irq", >>>>>> - CTLFLAG_RD,&adapter->link_irq, 0, >>>>>> + SYSCTL_ADD_UINT(ctx, child, OID_AUTO, "link_irq", >>>>>> + CTLFLAG_RD,&adapter->link_irq,0, >>>>>> "Link MSIX IRQ Handled"); >>>>>> SYSCTL_ADD_ULONG(ctx, child, OID_AUTO, "mbuf_alloc_fail", >>>>>> CTLFLAG_RD,&adapter->mbuf_alloc_failed, >>>>>> @@ -5108,11 +5102,13 @@ >>>>>> queue_list = SYSCTL_CHILDREN(queue_node); >>>>>> >>>>>> SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "txd_head", >>>>>> - CTLFLAG_RD, adapter, >>> E1000_TDH(txr->me), >>>>>> + CTLFLAG_RD, adapter, >>>>>> + E1000_TDH(txr->me), >>>>>> em_sysctl_reg_handler, "IU", >>>>>> "Transmit Descriptor Head"); >>>>>> SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "txd_tail", >>>>>> - CTLFLAG_RD, adapter, >>> E1000_TDT(txr->me), >>>>>> + CTLFLAG_RD, adapter, >>>>>> + E1000_TDT(txr->me), >>>>>> em_sysctl_reg_handler, "IU", >>>>>> "Transmit Descriptor Tail"); >>>>>> SYSCTL_ADD_ULONG(ctx, queue_list, OID_AUTO, "tx_irq", >>>>>> @@ -5123,11 +5119,13 @@ >>>>>> "Queue No Descriptor Available"); >>>>>> >>>>>> SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "rxd_head", >>>>>> - CTLFLAG_RD, adapter, >>> E1000_RDH(rxr->me), >>>>>> + CTLFLAG_RD, adapter, >>>>>> + E1000_RDH(rxr->me), >>>>>> em_sysctl_reg_handler, "IU", >>>>>> "Receive Descriptor Head"); >>>>>> SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "rxd_tail", >>>>>> - CTLFLAG_RD, adapter, >>> E1000_RDT(rxr->me), >>>>>> + CTLFLAG_RD, adapter, >>>>>> + E1000_RDT(rxr->me), >>>>>> em_sysctl_reg_handler, "IU", >>>>>> "Receive Descriptor Tail"); >>>>>> SYSCTL_ADD_ULONG(ctx, queue_list, OID_AUTO, "rx_irq", >>>>>> @@ -5141,19 +5139,19 @@ >>>>>> CTLFLAG_RD, NULL, "Statistics"); >>>>>> stat_list = SYSCTL_CHILDREN(stat_node); >>>>>> >>>>>> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "excess_coll", >>>>>> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "excess_coll", >>>>>> CTLFLAG_RD,&stats->ecol, >>>>>> "Excessive collisions"); >>>>>> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "single_coll", >>>>>> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "single_coll", >>>>>> CTLFLAG_RD,&stats->scc, >>>>>> "Single collisions"); >>>>>> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "multiple_coll", >>>>>> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "multiple_coll", >>>>>> CTLFLAG_RD,&stats->mcc, >>>>>> "Multiple collisions"); >>>>>> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "late_coll", >>>>>> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "late_coll", >>>>>> CTLFLAG_RD,&stats->latecol, >>>>>> "Late collisions"); >>>>>> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "collision_count", >>>>>> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "collision_count", >>>>>> CTLFLAG_RD,&stats->colc, >>>>>> "Collision Count"); >>>>>> SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "symbol_errors", >>>>>> @@ -5240,12 +5238,12 @@ >>>>>> SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, >>> "rx_frames_1024_1522", >>>>>> CTLFLAG_RD,&adapter->stats.prc1522, >>>>>> "1023-1522 byte frames received"); >>>>>> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_recvd", >>>>>> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_recvd", >>>>>> CTLFLAG_RD,&adapter->stats.gorc, >>>>>> "Good Octets Received"); >>>>>> >>>>>> /* Packet Transmission Stats */ >>>>>> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_txd", >>>>>> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_txd", >>>>>> CTLFLAG_RD,&adapter->stats.gotc, >>>>>> "Good Octets Transmitted"); >>>>>> SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "total_pkts_txd", >>>>>> >>>>>> -- >>>>>> ------------------- >>>>>> Mike Tancsa, tel +1 519 651 3400 >>>>>> Sentex Communications, mike@sentex.net >>>>>> Providing Internet services since 1994 www.sentex.net >>>>>> Cambridge, Ontario Canada http://www.tancsa.com/ >>>>>> >>>> >>>> -- >>>> ------------------- >>>> Mike Tancsa, tel +1 519 651 3400 >>>> Sentex Communications, mike@sentex.net >>>> Providing Internet services since 1994 www.sentex.net >>>> Cambridge, Ontario Canada http://www.tancsa.com/ >>>> _______________________________________________ >>>> 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 Jul 12 19:26:38 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A915106567C for ; Tue, 12 Jul 2011 19:26:38 +0000 (UTC) (envelope-from pkeusem@visi.com) Received: from g2host.com (mailfront3.g2host.com [208.42.184.241]) by mx1.freebsd.org (Postfix) with ESMTP id B5A668FC1F for ; Tue, 12 Jul 2011 19:26:37 +0000 (UTC) Received: from [173.30.51.17] (account pkeusem@visi.com HELO [172.16.175.217]) by mailfront3.g2host.com (CommuniGate Pro SMTP 5.3.11) with ESMTPSA id 20228641; Tue, 12 Jul 2011 14:26:36 -0500 Message-ID: <4E1C9FEA.2080608@visi.com> Date: Tue, 12 Jul 2011 14:26:34 -0500 From: Paul Keusemann User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Chuck Swiger References: <4E159C5A.5090702@visi.com> <13D65A4C-F874-4970-A070-AA0392416680@mac.com> In-Reply-To: <13D65A4C-F874-4970-A070-AA0392416680@mac.com> X-Is-From-Me: yes Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Debugging dropped shell connections over a VPN 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 Jul 2011 19:26:38 -0000 On 07/07/11 14:39, Chuck Swiger wrote: > On Jul 7, 2011, at 4:45 AM, Paul Keusemann wrote: >> My setup is something like this: >> - My local network is a mix of AIX, HP-UX, Linux, FreeBSD and Solaris machines running various OS versions. >> - My gateway / firewall machine is running FreeBSD-8.1-RELEASE-p1 with ipfw, nat and racoon for the firewall and VPN. >> >> The problem is that rlogin, ssh and telnet connections over the VPN get dropped after some period of inactivity. > You're probably getting NAT timeouts against the VPN connection if it is left idle. racoon ought to have a config setting called natt_keepalive which sends periodic keepalives-- see whether that's disabled. > > Regards, Thanks for the suggestions Chuck, sorry it's taken so long to respond but I had to reconfigure and rebuild my kernel to enable IPSEC_NAT_T in order to try this out. One thing that I did not explicitly mention before is that I am routing a network over the VPN. I did not have previously NAT-Traversal enabled nor was it configured in my kernel. After reconfiguring, compiling and installing the new kernel, I added the following to the phase 1 configuration for my VPN: timer { # Default is 20 seconds. natt_keepalive 10 sec; } # Enable NAT traversal. #nat_traversal on; nat_traversal force; # Enable IKE fragmentation. ike_frag on; # Enable ESP fragmentaion at 552 bytes. esp_frag 552; The only immediately noticeable change is that I am no longer getting the following warnings at racoon startup: WARNING: setsockopt(UDP_ENCAP_ESPINUDP_NON_IKE): UDP_ENCAP Invalid argument I assume this is the result of adding IPSEC_NAT_T to the kernel config. My shell connections are still being dropped, so I'm pretty much back to square one. So, any other ideas on how to debug this? Anybody know how to get racoon to log everything to one file? Right now, depending on the log level, I am getting messages in racoon.log (specified with -l at startup), messages and debug.log. It would really be nice to have just one log to look at. -- Paul Keusemann pkeusem@visi.com 4266 Joppa Court (952) 894-7805 Savage, MN 55378 From owner-freebsd-net@FreeBSD.ORG Tue Jul 12 19:53:06 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 275711065672; Tue, 12 Jul 2011 19:53:06 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id B5AAB8FC0C; Tue, 12 Jul 2011 19:53:05 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p6CJr1ZI034897; Tue, 12 Jul 2011 15:53:01 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4E1CA63C.10406@sentex.net> Date: Tue, 12 Jul 2011 15:53:32 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Hooman Fazaeli References: <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> <1296597827.2326.12.camel@hitfishpass-lx.corp.yahoo.com> <4D48C973.7080503@sentex.net> <4D49A26B.5050803@sentex.net> <1296842996.2233.0.camel@hitfishpass-lx.corp.yahoo.com> <4D4F3497.6050505@sentex.net> <4E1C9A88.5080102@sepehrs.com> In-Reply-To: <4E1C9A88.5080102@sepehrs.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: "freebsd-net@freebsd.org" , "freebsd-hardware@freebsd.org" Subject: Re: em driver, 82574L chip, and possibly ASPM 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 Jul 2011 19:53:06 -0000 On 7/12/2011 3:03 PM, Hooman Fazaeli wrote: > > I have similar problems on a couple of 7.3 boxes with latest driver form > -CURRENT. > I just wanted to know if your 7 boxes work fine so I look for cause else > where. Yes, all has been working quite well for me to date. em1@pci0:11:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0003[140] = Serial 1 001517ffffed68a4 em1: port 0x2000-0x201f mem 0xb4100000-0xb411ffff,0xb4120000-0xb4123fff irq 16 at device 0.0 on pci11 em1: Using MSIX interrupts with 3 vectors em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Tue Jul 12 20:23:40 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 263BF1065673; Tue, 12 Jul 2011 20:23:40 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by mx1.freebsd.org (Postfix) with ESMTP id E689A8FC12; Tue, 12 Jul 2011 20:23:39 +0000 (UTC) Received: from [10.9.200.131] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 12 Jul 2011 13:27:15 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Tue, 12 Jul 2011 13:22:25 -0700 From: "David Christensen" To: "Charles Sprickman" Date: Tue, 12 Jul 2011 13:22:14 -0700 Thread-Topic: bce packet loss Thread-Index: AcxASZhXV0vuHBD2R1y0D3Uzm2S4AwAhBZiA Message-ID: <5D267A3F22FD854F8F48B3D2B523819385F12FEBE6@IRVEXCHCCR01.corp.ad.broadcom.com> References: <20110706201509.GA5559@michelle.cdnetworks.com> <20110707174233.GB8702@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B523819385C32D96B7@IRVEXCHCCR01.corp.ad.broadcom.com> <5D267A3F22FD854F8F48B3D2B523819385F12FE86B@IRVEXCHCCR01.corp.ad.broadcom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: EbwW H0fU JQNt KQo+ Lnx5 NgeI N3gT RPsy UwvG Wwhu adPn csZA g5wE h5Vj kSVv pOKG; 4; ZABhAHYAaQBkAGMAaABAAGYAcgBlAGUAYgBzAGQALgBvAHIAZwA7AGYAcgBlAGUAYgBzAGQALQBuAGUAdABAAGYAcgBlAGUAYgBzAGQALgBvAHIAZwA7AHAAeQB1AG4AeQBoAEAAZwBtAGEAaQBsAC4AYwBvAG0AOwBzAHAAbwByAGsAQABiAHcAYQB5AC4AbgBlAHQA; Sosha1_v1; 7; {9DCC3B7E-B2CE-4D59-AA8E-B8F479F269FD}; ZABhAHYAaQBkAGMAaABAAGIAcgBvAGEAZABjAG8AbQAuAGMAbwBtAA==; Tue, 12 Jul 2011 20:22:14 GMT;UgBFADoAIABiAGMAZQAgAHAAYQBjAGsAZQB0ACAAbABvAHMAcwA= x-cr-puzzleid: {9DCC3B7E-B2CE-4D59-AA8E-B8F479F269FD} acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 620271A962O24003635-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: YongHyeon PYUN , "freebsd-net@freebsd.org" , David Christensen Subject: RE: bce packet loss 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 Jul 2011 20:23:40 -0000 > > There won't be any indication in the driver since flow control > > is managed in hardware. You'd need a wire capture to see that > > bce(4) has stopped sending frames in response to receiving an > > XOFF flow control frame or started sending frames in response > > to receiving an XON flow control frame. >=20 > Ah. I was hoping for something in the ifconfig output. I'll see if > tcpdump and wireshark can tell me anything about this host. >=20 Flow control frames are consumed by the MAC and aren't passed to the OS stack so you won't see them with a host based packet capture application like tcpdump. You'd need something like a JDSU Xgig protocol analyzer to see them on the wire. > One the one host (w/bce) I just set to full auto, the switch claims to > have negotiated 1000FD w/flow control (this specifically shows as > "auto+enabled" on the switch side). >=20 > I see that the "sysctl dev.bce.1" tree has some info, and I can see that > the NIC is receiving flow control frames: >=20 > dev.bce.1.stat_XonPauseFramesReceived: 16638 > dev.bce.1.stat_XoffPauseFramesReceived: 17239 >=20 > These lines are a bit puzzling though: >=20 > dev.bce.1.stat_FlowControlDone: 0 > dev.bce.1.stat_XoffStateEntered: 0 Auto-negotiation occurs between PHYs and then the link comes up. When link is up bce(4) will configure the MAC based on the auto-neg results returned by brgphy(4) (the switch should follow a similar procedure on its side). Flow control occurs at the MAC level. It looks like the MAC is not configured to=20 support flow control as negotiated by the PHY during auto-neg, resulting in flow control frames being ignored. The driver will set this in the MAC based on PHY results: http://fxr.watson.org/fxr/source/dev/bce/if_bce.c#L2046 Either the PHY results are coming back incorrectly or it may be firmware on bce(4) is disabling the behavior even though bce(4) correctly enables it. Dave From owner-freebsd-net@FreeBSD.ORG Tue Jul 12 22:42:52 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7385106564A for ; Tue, 12 Jul 2011 22:42:52 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by mx1.freebsd.org (Postfix) with ESMTP id AF0E98FC18 for ; Tue, 12 Jul 2011 22:42:52 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp022.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LO8003E1SFG1X70@asmtp022.mac.com> for freebsd-net@freebsd.org; Tue, 12 Jul 2011 15:42:52 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-07-12_09:2011-07-12, 2011-07-12, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1107120174 From: Chuck Swiger In-reply-to: <4E1C9FEA.2080608@visi.com> Date: Tue, 12 Jul 2011 15:42:51 -0700 Message-id: <5458975C-9FA3-4AB6-9535-3D7BD152378B@mac.com> References: <4E159C5A.5090702@visi.com> <13D65A4C-F874-4970-A070-AA0392416680@mac.com> <4E1C9FEA.2080608@visi.com> To: Paul Keusemann X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: Debugging dropped shell connections over a VPN 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 Jul 2011 22:42:52 -0000 On Jul 12, 2011, at 12:26 PM, Paul Keusemann wrote: > So, any other ideas on how to debug this? Gather data with tcpdump. If you do it on one of the VPN endpoints, you ought to see the VPN contents rather than just packets going by in the encrypted tunnel. > Anybody know how to get racoon to log everything to one file? Right now, depending on the log level, I am getting messages in racoon.log (specified with -l at startup), messages and debug.log. It would really be nice to have just one log to look at. This is likely governed by /etc/syslog.conf, but if you specify -l then racoon shouldn't use syslog logging. Regards, -- -Chuck From owner-freebsd-net@FreeBSD.ORG Wed Jul 13 03:30:13 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9465F1065673 for ; Wed, 13 Jul 2011 03:30:13 +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 6ADB28FC1B for ; Wed, 13 Jul 2011 03:30:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6D3UDl0050239 for ; Wed, 13 Jul 2011 03:30:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6D3UDZS050234; Wed, 13 Jul 2011 03:30:13 GMT (envelope-from gnats) Date: Wed, 13 Jul 2011 03:30:13 GMT Message-Id: <201107130330.p6D3UDZS050234@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Kelly Yancey Cc: Subject: Re: kern/152036: [libc] getifaddrs(3) returns truncated sockaddrs for netmasks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kelly Yancey List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 03:30:13 -0000 The following reply was made to PR kern/152036; it has been noted by GNATS. From: Kelly Yancey To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/152036: [libc] getifaddrs(3) returns truncated sockaddrs for netmasks Date: Tue, 12 Jul 2011 19:24:22 -0700 Thanks, now lets just change the category to kern to reflect=85oh, wait.= From owner-freebsd-net@FreeBSD.ORG Wed Jul 13 09:48:24 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA482106564A for ; Wed, 13 Jul 2011 09:48:24 +0000 (UTC) (envelope-from adrian.minta@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 927508FC14 for ; Wed, 13 Jul 2011 09:48:24 +0000 (UTC) Received: by gxk28 with SMTP id 28so2870623gxk.13 for ; Wed, 13 Jul 2011 02:48:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=4QZby0hWHSwoB0dG5GLHM5YXDXCxSBUYagfTr+Ct2Dw=; b=Rx3YGqul+H5R9fM2wMAIEATRmBPax3z04b9BYrVl8U6s3/xPW+UHBAz8x3oZz5JITQ vyUPNgJqeYSlAfniuyR79BpQ6UaE/ujV+fbMibJoZ+AWOZ+CTEjnobUO4z8xIZ0ugj/t 8h8fayV8Uqro0aFWWWwdJWxOjtdC1L9uuG15g= MIME-Version: 1.0 Received: by 10.236.108.134 with SMTP id q6mr570599yhg.343.1310550502252; Wed, 13 Jul 2011 02:48:22 -0700 (PDT) Received: by 10.236.107.231 with HTTP; Wed, 13 Jul 2011 02:48:22 -0700 (PDT) Date: Wed, 13 Jul 2011 12:48:22 +0300 Message-ID: From: Adrian M To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: FreeBSD 8.2, MPD5 - crash when net.isr.bindthreads=0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 09:48:24 -0000 Hi, I always get a kernel crash when "net.isr.bindthreads=0" and around 4700 l2tp sessions. With "net.isr.bindthreads=1" the system is stable and I manage to get around 6500 sessions. If somebody is interested here are the crash details: http://pluto.stsisp.ro/crash-isr/ -- Best regards, Adrian Minta From owner-freebsd-net@FreeBSD.ORG Wed Jul 13 11:04:09 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14E5B10656D3 for ; Wed, 13 Jul 2011 11:04:09 +0000 (UTC) (envelope-from vladimir.budnev@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id A5B238FC0C for ; Wed, 13 Jul 2011 11:04:08 +0000 (UTC) Received: by vws18 with SMTP id 18so5673374vws.13 for ; Wed, 13 Jul 2011 04:04:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=t4j3mLm83y/iZM51aiDHiW9Kbtxp6UjaVjlLCOmSxXw=; b=ZhFK6aE8Mxn+UON7Ur39lZk4A5q4vzjrEw56kM2hHAaltMlQTFTlDqY2phQ9Ercmp0 Q/b+Apa0lE0UV3VWOEJdmtFm11J1mAmp3BXIH5N0j0MpdqX72xVxDNY440GRS1DJt6wI EsJU4dammAbiI6uac2fPYeghJay47+jHbJ7N0= MIME-Version: 1.0 Received: by 10.52.65.228 with SMTP id a4mr1094082vdt.137.1310553446833; Wed, 13 Jul 2011 03:37:26 -0700 (PDT) Received: by 10.220.178.129 with HTTP; Wed, 13 Jul 2011 03:37:26 -0700 (PDT) Date: Wed, 13 Jul 2011 14:37:26 +0400 Message-ID: From: Vladimir Budnev To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: (TCP/IP) Server side sends RST after 3-way handshake.Syn flood defense or queue overflow? 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 Jul 2011 11:04:09 -0000 Hello. Iv faced some problem and seems don't realize the mechanincs why does it occures. First of all i'd like to notice that my freebsd knowledge and expirience is limited, especially in such "strange" cases. In details(code example ill be at the end): System: # uname -spr FreeBSD 7.2-RELEASE amd64 We have simple TCP client and server. Server is very casual, it listens on some port in while->select->accept loop. Client knocks on server port and sends some data and closes the port. First it was designed for sending data 3-5/times per minute. But once during test I'v noticed that if client sends data very fast (more precisely it opens and closes socket to server very fast) there is "54 - Connection reset by peer" error on call to "connect".(on client side ofc) Some illustration from tcpdump: (test on localhost.server side is port 10002.i'v cuted other fields for simplicity) <...> 13:48:58.491229 IP 127.0.0.1.56677 > 127.0.0.1.10002: S 13:48:58.491255 IP 127.0.0.1.10002 > 127.0.0.1.56677: S ack 13:48:58.491266 IP 127.0.0.1.56677 > 127.0.0.1.10002: . ack 13:48:58.491300 IP 127.0.0.1.56677 > 127.0.0.1.10002: P 13:48:58.491346 IP 127.0.0.1.56677 > 127.0.0.1.10002: F 13:48:58.491365 IP 127.0.0.1.10002 > 127.0.0.1.56677: . ack 13:48:58.491466 IP 127.0.0.1.55238 > 127.0.0.1.10002: S // 13:48:58.491490 IP 127.0.0.1.10002 > 127.0.0.1.55238: S ack // handshake 13:48:58.491503 IP 127.0.0.1.55238 > 127.0.0.1.10002: . ack // 13:48:58.491536 IP 127.0.0.1.55238 > 127.0.0.1.10002: P <--data 13:48:58.491580 IP 127.0.0.1.55238 > 127.0.0.1.10002: F <-- client closes session 13:48:58.491599 IP 127.0.0.1.10002 > 127.0.0.1.55238: . ack // OK 13:48:58.491701 IP 127.0.0.1.60212 > 127.0.0.1.10002: S 13:48:58.491726 IP 127.0.0.1.10002 > 127.0.0.1.60212: S ack 13:48:58.491738 IP 127.0.0.1.60212 > 127.0.0.1.10002: . ack 13:48:58.491745 IP 127.0.0.1.10002 > 127.0.0.1.60212: R <-- this is strange answer.Why? 13:48:58.491887 IP 127.0.0.1.60804 > 127.0.0.1.10002: S 13:48:58.491914 IP 127.0.0.1.10002 > 127.0.0.1.60804: S ack 13:48:58.491924 IP 127.0.0.1.60804 > 127.0.0.1.10002: . ack 13:48:58.491931 IP 127.0.0.1.10002 > 127.0.0.1.60804: R <...> Some connections were OK but then server application begin to send RST right after handshake. Tuning listen backlog parameter doesn't help much, BUT what really solves the "problem" is increasing time interval between client requests.egusleep(10000) solves the "problem" at all. Iv maned for some tuning like syncache and syncookies but nothing usefull, or i missed something.But here they are: # sysctl -a | grep syncache net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.cachelimit: 15360 net.inet.tcp.syncache.bucketlimit: 30 ipfw rules allows any from any, nothing special. QUESTION: So the question is why such thing happening?Is this is some freebsd defense from syn flood?(to be honest don't think so because seems there is no fixed "ALLOWED syn/syn-ack/ack per seconds"). It more looks like some queue overflow,but I don't know what queue and how it can be enlarged. If i can provide some more info to clear some aspects I will! Thanks in advance, Vladimir. I'v wrote some simplified(as simply as possible imho:)) small client and server example which reproduses the situation (at least on our test stend), here is the code. its not perfect, but i think its easy to read as example: NOTICE: it writes logs to local0 level. //------------------------------------------------------------------------------ //------------------------------------client.c //------------------------------------------------------------------------------ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include uint8_t progname[]="client"; #define MAX_ITER 300 int send_msg(); int main(int argc,char **argv){ int res=0; uint16_t counter=0; openlog(progname,LOG_NDELAY,LOG_LOCAL0); syslog(LOG_DEBUG,"Started"); while( counter<=MAX_ITER ){ syslog(LOG_DEBUG,"Attemp #%d",counter); send_msg(); counter++; } return res; } int send_msg(){ int sock; int res; struct sockaddr_in src_addr; struct sockaddr_in dst_addr; struct timeval tv; uint8_t target_addr[]="127.0.0.1"; uint8_t target_port[]="10002"; sock=socket(AF_INET,SOCK_STREAM,0); if(sock<0){ syslog(LOG_ERR,"ERROR on socket: %s\n",strerror(errno)); return -1; } src_addr.sin_family = AF_INET; src_addr.sin_port = htons(INADDR_ANY); src_addr.sin_addr.s_addr = INADDR_ANY; res=bind(sock,(struct sockaddr*)&src_addr,sizeof(struct sockaddr_in)); if(res<0){ syslog(LOG_ERR,"ERROR on bind: %s\n",strerror(errno)); close(sock); return -1; } dst_addr.sin_family = AF_INET; dst_addr.sin_port = htons(atoi(target_port)); dst_addr.sin_addr.s_addr = inet_addr(target_addr); syslog(LOG_DEBUG,"Connecting to addr %s : %s",target_addr,target_port); res=connect(sock,(struct sockaddr *)&dst_addr,sizeof(struct sockaddr_in)); if (res<0){ syslog(LOG_ERR,"ERROR: connection to server failed: %d - %s",errno,strerror(errno)); close(sock); return -1; } close(sock); return 0; } //------------------------------------------------------------------------------ //--------------------------server.c //------------------------------------------------------------------------------ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #define SELECT_TIMEOUT_S 10 uint8_t progname[]="server"; int wait_loop(uint8_t*,uint16_t); int main(int argc,char **argv){ int res=0; openlog(progname,LOG_NDELAY,LOG_LOCAL0); syslog(LOG_DEBUG,"Started"); res=wait_loop( "127.0.0.1",atoi("10002") ); return res; } int wait_loop(uint8_t* listen_ip,uint16_t listen_port) { int32_t listen_sock; int32_t client_sock; struct sockaddr_in listen_addr; int res; fd_set readfds; pid_t process_id; struct timeval tv; uint32_t client_addr_size=sizeof(struct sockaddr_in); struct sockaddr_in client_addr; listen_sock=socket(AF_INET,SOCK_STREAM,0); if(listen_sock<0){ syslog(LOG_ERR,"ERROR on select: %s\n",strerror(errno)); return -1; } listen_addr.sin_family = AF_INET; listen_addr.sin_port = htons(listen_port); listen_addr.sin_addr.s_addr = inet_addr(listen_ip); res=bind(listen_sock,(struct sockaddr*)&listen_addr,sizeof(struct sockaddr_in)); if(res<0){ syslog(LOG_ERR,"ERROR on bind: %s\n",strerror(errno)); close(listen_sock); return -1; } res=listen(listen_sock,100); // just for example,tuning this doesnt help much if(res<0){ syslog(LOG_ERR,"ERROR on listen: %s\n",strerror(errno)); close(listen_sock); return -1; } syslog(LOG_DEBUG,"Listening at %s:%d",listen_ip,listen_port); while(1) { FD_ZERO(&readfds); FD_SET(listen_sock,&readfds); tv.tv_sec=SELECT_TIMEOUT_S; tv.tv_usec=0; res=select(listen_sock+1,&readfds,0,0,&tv); if ( res!=-1 && FD_ISSET( listen_sock,&readfds ) ){ client_sock=accept(listen_sock,(struct sockaddr*)&client_addr,&client_addr_size); if( client_sock<0 ){ syslog(LOG_ERR,"ERROR on accept: %s\n",strerror(errno)); } syslog(LOG_DEBUG,"Request from: %s:%d\n",inet_ntoa(client_addr.sin_addr),client_addr.sin_port); usleep(100000);// some useful job here which take some time to execute :) close(client_sock); }//select if }//while loop return 0; } From owner-freebsd-net@FreeBSD.ORG Wed Jul 13 12:06:28 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A94AA106564A for ; Wed, 13 Jul 2011 12:06:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7FDC38FC13 for ; Wed, 13 Jul 2011 12:06:28 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 35CE246B0D; Wed, 13 Jul 2011 08:06:28 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CB4DA8A037; Wed, 13 Jul 2011 08:06:27 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Wed, 13 Jul 2011 07:57:18 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107130757.19178.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 13 Jul 2011 08:06:27 -0400 (EDT) Cc: Vladimir Budnev Subject: Re: (TCP/IP) Server side sends RST after 3-way handshake.Syn flood defense or queue overflow? 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 Jul 2011 12:06:28 -0000 On Wednesday, July 13, 2011 6:37:26 am Vladimir Budnev wrote: > Hello. > > Iv faced some problem and seems don't realize the mechanincs why does it > occures. > First of all i'd like to notice that my freebsd knowledge and expirience is > limited, especially in such "strange" cases. > > In details(code example ill be at the end): > > System: > # uname -spr > FreeBSD 7.2-RELEASE amd64 > > We have simple TCP client and server. > > Server is very casual, it listens on some port in while->select->accept > loop. > > Client knocks on server port and sends some data and closes the port. > First it was designed for sending data 3-5/times per minute. But once during > test I'v noticed that if client sends data very fast (more precisely it > opens and closes socket to server very fast) there is > "54 - Connection reset by peer" error on call to "connect".(on client side > ofc) > > Some illustration from tcpdump: > (test on localhost.server side is port 10002.i'v cuted other fields for > simplicity) > <...> > 13:48:58.491229 IP 127.0.0.1.56677 > 127.0.0.1.10002: S > 13:48:58.491255 IP 127.0.0.1.10002 > 127.0.0.1.56677: S ack > 13:48:58.491266 IP 127.0.0.1.56677 > 127.0.0.1.10002: . ack > 13:48:58.491300 IP 127.0.0.1.56677 > 127.0.0.1.10002: P > 13:48:58.491346 IP 127.0.0.1.56677 > 127.0.0.1.10002: F > 13:48:58.491365 IP 127.0.0.1.10002 > 127.0.0.1.56677: . ack > > 13:48:58.491466 IP 127.0.0.1.55238 > 127.0.0.1.10002: S // > 13:48:58.491490 IP 127.0.0.1.10002 > 127.0.0.1.55238: S ack // handshake > 13:48:58.491503 IP 127.0.0.1.55238 > 127.0.0.1.10002: . ack // > 13:48:58.491536 IP 127.0.0.1.55238 > 127.0.0.1.10002: P <--data > 13:48:58.491580 IP 127.0.0.1.55238 > 127.0.0.1.10002: F <-- client > closes session > 13:48:58.491599 IP 127.0.0.1.10002 > 127.0.0.1.55238: . ack // OK > > 13:48:58.491701 IP 127.0.0.1.60212 > 127.0.0.1.10002: S > 13:48:58.491726 IP 127.0.0.1.10002 > 127.0.0.1.60212: S ack > 13:48:58.491738 IP 127.0.0.1.60212 > 127.0.0.1.10002: . ack > 13:48:58.491745 IP 127.0.0.1.10002 > 127.0.0.1.60212: R <-- this is > strange answer.Why? > > 13:48:58.491887 IP 127.0.0.1.60804 > 127.0.0.1.10002: S > 13:48:58.491914 IP 127.0.0.1.10002 > 127.0.0.1.60804: S ack > 13:48:58.491924 IP 127.0.0.1.60804 > 127.0.0.1.10002: . ack > 13:48:58.491931 IP 127.0.0.1.10002 > 127.0.0.1.60804: R > <...> > > Some connections were OK but then server application begin to send RST right > after handshake. > Tuning listen backlog parameter doesn't help much, BUT what really solves > the "problem" is increasing time interval between client > requests.egusleep(10000) solves the "problem" at all. > > Iv maned for some tuning like syncache and syncookies but nothing usefull, > or i missed something.But here they are: > > # sysctl -a | grep syncache > net.inet.tcp.syncache.rst_on_sock_fail: 1 > net.inet.tcp.syncache.rexmtlimit: 3 > net.inet.tcp.syncache.hashsize: 512 > net.inet.tcp.syncache.count: 0 > net.inet.tcp.syncache.cachelimit: 15360 > net.inet.tcp.syncache.bucketlimit: 30 > > > ipfw rules allows any from any, nothing special. > > QUESTION: > So the question is why such thing happening?Is this is some freebsd defense > from syn flood?(to be honest don't think so because seems there is no fixed > "ALLOWED syn/syn-ack/ack per seconds"). It more looks like some queue > overflow,but I don't know what queue and how it can be enlarged. > > If i can provide some more info to clear some aspects I will! > > Thanks in advance, Vladimir. Do you have any of these in your netstat -s -p tcp output: 6186 embryonic connections dropped 63889 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 63889 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 63889 cookies sent 0 cookies received It is normal for syncache entries added == completed == cookies sent, I'm mostly curious about anything else besides that. It is possible when using the syncache to have the network stack decide it can't create a connection until it gets to the end of the 3-way handshake due to resource limits, etc. In that case the end of the 3-way handshake will get a RST in response. However, if your app just sends data and calls close() without doing any reads, it might close() succesfully while the data is in flight before the client machine sees the RST, so the client app will not see any errors. If the RST arrives before you finish calling write() and close() then you will get ECONNRESET errors from write() and close(). You can try turning off the syncache and syncookies as a test. This will probably trigger more ECONNRESET errors in connect() (which your app will need to retry on). However, the better fix is to track down what is causing your connections to be dropped in the first place, e.g. if you are hitting the limit on inpcbs (look for failures in vmstat -z output) and fix that. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Jul 13 12:37:25 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A3A2106566B for ; Wed, 13 Jul 2011 12:37:25 +0000 (UTC) (envelope-from vladimir.budnev@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 20B7D8FC19 for ; Wed, 13 Jul 2011 12:37:24 +0000 (UTC) Received: by vws18 with SMTP id 18so5741848vws.13 for ; Wed, 13 Jul 2011 05:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=INCkpSjooey2gwBTpGGCcopKtYQeTS+pVtvVdZfT6/g=; b=aolCNzsxZ3WW6Yea8PHJoNdYChzGSwWO6yUbBzsFd0oBg/mFWBRoyiIgRjJc6p0jfK PTUAWENdNNgWwpMUw5ZkDl/isQNtv04g8DVYkwcRSj2x3ivMc05CZ1I4Y/V7NTeNX9Ax eEMgM/yR8X1GKe6y4T0ymZIBM42iHogYhM8kw= MIME-Version: 1.0 Received: by 10.52.65.228 with SMTP id a4mr1205928vdt.137.1310560644343; Wed, 13 Jul 2011 05:37:24 -0700 (PDT) Received: by 10.220.178.129 with HTTP; Wed, 13 Jul 2011 05:37:24 -0700 (PDT) In-Reply-To: <201107130757.19178.jhb@freebsd.org> References: <201107130757.19178.jhb@freebsd.org> Date: Wed, 13 Jul 2011 16:37:24 +0400 Message-ID: From: Vladimir Budnev To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: (TCP/IP) Server side sends RST after 3-way handshake.Syn flood defense or queue overflow? 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 Jul 2011 12:37:25 -0000 First of all thanks for response! It is normal for syncache entries added == completed == cookies sent, I'm > mostly curious about anything else besides that. It is possible when using > the syncache to have the network stack decide it can't create a connection > until it gets to the end of the 3-way handshake due to resource limits, > etc. > In that case the end of the 3-way handshake will get a RST in response. > statistics i have: (cutted from netstat -s -p tcp) 89514 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 50220 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 39294 aborted 0 badack 0 unreach 0 zone failures 89514 cookies sent According to your hint I see nonzero aborted field, but dont know how to get the reason/interpret this. > However, if your app just sends data and calls close() without doing any > reads, it might close() succesfully while the data is in flight before the > client machine sees the RST, so the client app will not see any errors. If > the RST arrives before you finish calling write() and close() then you will > get ECONNRESET errors from write() and close(). > Hm..hope i get your idea, the difference is that client application recieve ECONNRESET as result to _connect_ call not as result from write/read/close, at that point i cant ignore it. I can spin/wait and try again, but that way every N iterations when problem occures there will be this "problem". As i mentioned(and in code example) client on every iteration makes connect/close, and those come very fast. Mb i misunderstood smth. You can try turning off the syncache and syncookies as a test. This will > probably trigger more ECONNRESET errors in connect() (which your app will > need > to retry on). Spin idea...yeah it sounds friendly but i dont think sy/syn-ack/ack/rst flood would be great:( > However, the better fix is to track down what is causing your > connections to be dropped in the first place, e.g. if you are hitting the > limit on inpcbs (look for failures in vmstat -z output) and fix that. > # vmstat -z ITEM SIZE LIMIT USED FREE REQUESTS FAILURES <...> inpcb: 288, 25610, 6, 5155, 142849, 0 tcpcb: 728, 25600, 6, 454, 142849, 0 <...> Those ones looks ok? > > -- > John Baldwin > From owner-freebsd-net@FreeBSD.ORG Wed Jul 13 14:06:01 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B4C81065670 for ; Wed, 13 Jul 2011 14:06:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7033E8FC1D for ; Wed, 13 Jul 2011 14:06:01 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E414A46B0A; Wed, 13 Jul 2011 10:06:00 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8380E8A02F; Wed, 13 Jul 2011 10:06:00 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Wed, 13 Jul 2011 10:05:55 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <201107130757.19178.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107131005.55820.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 13 Jul 2011 10:06:00 -0400 (EDT) Cc: Vladimir Budnev Subject: Re: (TCP/IP) Server side sends RST after 3-way handshake.Syn flood defense or queue overflow? 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 Jul 2011 14:06:01 -0000 On Wednesday, July 13, 2011 8:37:24 am Vladimir Budnev wrote: > statistics i have: > (cutted from netstat -s -p tcp) > 89514 syncache entries added > 0 retransmitted > 0 dupsyn > 0 dropped > 50220 completed > 0 bucket overflow > 0 cache overflow > 0 reset > 0 stale > 39294 aborted > 0 badack > 0 unreach > 0 zone failures > 89514 cookies sent > According to your hint I see nonzero aborted field, but dont know how to get > the reason/interpret this. Yep, the aborted entries are likely your resets. > > However, if your app just sends data and calls close() without doing any > > reads, it might close() succesfully while the data is in flight before the > > client machine sees the RST, so the client app will not see any errors. If > > the RST arrives before you finish calling write() and close() then you will > > get ECONNRESET errors from write() and close(). > > > > Hm..hope i get your idea, the difference is that client application recieve > ECONNRESET as result to _connect_ call not as result from write/read/close, > at that point i cant ignore it. I can spin/wait and try again, but that way > every N iterations when problem occures there will be this "problem". As i > mentioned(and in code example) client on every iteration makes > connect/close, and those come very fast. > Mb i misunderstood smth. Ah, when I was tracking down a similar issue I was only seeing errors on write (or sometimes not at all) not on connect(). A bit odd you are getting errors on connect(). Maybe the RST is arriving so fast the kernel notices it and marks the socket error before the process asleep in connect() gets a chance to run after it is awakened by the SYN/ACK processing. > You can try turning off the syncache and syncookies as a test. This will > > probably trigger more ECONNRESET errors in connect() (which your app will > > need > > to retry on). > > Spin idea...yeah it sounds friendly but i dont think sy/syn-ack/ack/rst > flood would be great:( Yes, fixing it for real would be better. > > However, the better fix is to track down what is causing your > > connections to be dropped in the first place, e.g. if you are hitting the > > limit on inpcbs (look for failures in vmstat -z output) and fix that. > > > # vmstat -z > ITEM SIZE LIMIT USED FREE REQUESTS > FAILURES > <...> > inpcb: 288, 25610, 6, 5155, > 142849, 0 > tcpcb: 728, 25600, 6, 454, > 142849, 0 > <...> > Those ones looks ok? Hmm, perhaps compare the 'kern.ipc.numopensockets' and 'kern.ipc.maxsockets' tunables under load on the server? -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Jul 13 19:46:23 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DCAC106564A; Wed, 13 Jul 2011 19:46:23 +0000 (UTC) (envelope-from pluknet@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7612C8FC08; Wed, 13 Jul 2011 19:46:23 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6DJkNgU082073; Wed, 13 Jul 2011 19:46:23 GMT (envelope-from pluknet@freefall.freebsd.org) Received: (from pluknet@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6DJkNhj082069; Wed, 13 Jul 2011 19:46:23 GMT (envelope-from pluknet) Date: Wed, 13 Jul 2011 19:46:23 GMT Message-Id: <201107131946.p6DJkNhj082069@freefall.freebsd.org> To: pluknet@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: pluknet@FreeBSD.org Cc: Subject: Re: kern/158873: When I launch pf daemon, I have a kernel panic 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 Jul 2011 19:46:23 -0000 Synopsis: When I launch pf daemon, I have a kernel panic Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: pluknet Responsible-Changed-When: Wed Jul 13 19:45:29 UTC 2011 Responsible-Changed-Why: Reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=158873 From owner-freebsd-net@FreeBSD.ORG Wed Jul 13 20:00:23 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11E221065672 for ; Wed, 13 Jul 2011 20:00:23 +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 F159E8FC17 for ; Wed, 13 Jul 2011 20:00:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6DK0Mms090808 for ; Wed, 13 Jul 2011 20:00:22 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6DK0M5P090806; Wed, 13 Jul 2011 20:00:22 GMT (envelope-from gnats) Date: Wed, 13 Jul 2011 20:00:22 GMT Message-Id: <201107132000.p6DK0M5P090806@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Sergey Kandaurov Cc: Subject: Re: kern/158873: When I launch pf daemon, I have a kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sergey Kandaurov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 20:00:23 -0000 The following reply was made to PR kern/158873; it has been noted by GNATS. From: Sergey Kandaurov To: bug-followup@FreeBSD.org, gobledb@gmail.com Cc: Subject: Re: kern/158873: When I launch pf daemon, I have a kernel panic Date: Wed, 13 Jul 2011 23:50:24 +0400 I think we need to merge net/if_pfsync.c 1.113 from vendor. Below is a more complete crash info. panic: _mtx_lock_sleep: recursed on non-recursive mutex pf task mtx @ /usr/src/sys/modules/pfsync/../../contrib/pf/net/if_pfsync.c:3163 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff802db93a = db_trace_self_wrapper+0x2a kdb_backtrace() at 0xffffffff8047f407 = kdb_backtrace+0x37 panic() at 0xffffffff80448017 = panic+0x187 _mtx_lock_sleep() at 0xffffffff80437513 = _mtx_lock_sleep+0x343 _mtx_lock_flags() at 0xffffffff8043768c = _mtx_lock_flags+0x16c pfsync_send_plus() at 0xffffffff81072eda = pfsync_send_plus+0xaa pfsync_clear_states() at 0xffffffff81072ffe = pfsync_clear_states+0x6e pfioctl() at 0xffffffff8106024b = pfioctl+0x1c0b devfs_ioctl_f() at 0xffffffff803c442a = devfs_ioctl_f+0x7a kern_ioctl() at 0xffffffff8049984e = kern_ioctl+0xbe ioctl() at 0xffffffff80499aed = ioctl+0xfd syscallenter() at 0xffffffff8048e30b = syscallenter+0x1cb syscall() at 0xffffffff806bd630 = syscall+0x60 Xfast_syscall() at 0xffffffff806a853d = Xfast_syscall+0xdd --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800da70ac, rsp = 0x7fffffffd528, rbp = 0 --- KDB: enter: panic [ thread pid 48453 tid 100192 ] Stopped at 0xffffffff8047f01b = kdb_enter+0x3b: movq $0,0x6eeb82(%rip) -- wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Wed Jul 13 21:00:25 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B6741065675 for ; Wed, 13 Jul 2011 21:00:25 +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 1B5438FC0C for ; Wed, 13 Jul 2011 21:00:25 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6DL0Oc2046236 for ; Wed, 13 Jul 2011 21:00:24 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6DL0Obh046235; Wed, 13 Jul 2011 21:00:24 GMT (envelope-from gnats) Date: Wed, 13 Jul 2011 21:00:24 GMT Message-Id: <201107132100.p6DL0Obh046235@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Sergey Kandaurov Cc: Subject: Re: kern/158873: When I launch pf daemon, I have a kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sergey Kandaurov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 21:00:25 -0000 The following reply was made to PR kern/158873; it has been noted by GNATS. From: Sergey Kandaurov To: bug-followup@FreeBSD.org, gobledb@gmail.com Cc: Subject: Re: kern/158873: When I launch pf daemon, I have a kernel panic Date: Thu, 14 Jul 2011 00:50:38 +0400 --000e0cd4c08e974e9704a7f99174 Content-Type: text/plain; charset=ISO-8859-1 Something like this will probably fix the panic (attached). -- wbr, pluknet --000e0cd4c08e974e9704a7f99174 Content-Type: text/x-patch; charset=US-ASCII; name="if_pfsync.diff" Content-Disposition: attachment; filename="if_pfsync.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gq2rgfnx0 SW5kZXg6IHN5cy9jb250cmliL3BmL25ldC9pZl9wZnN5bmMuYwo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMv Y29udHJpYi9wZi9uZXQvaWZfcGZzeW5jLmMJKHJldmlzaW9uIDIyMzgyMikKKysrIHN5cy9jb250 cmliL3BmL25ldC9pZl9wZnN5bmMuYwkod29ya2luZyBjb3B5KQpAQCAtMSw0ICsxLDUgQEAKIC8q CSRPcGVuQlNEOiBpZl9wZnN5bmMuYyx2IDEuMTEwIDIwMDkvMDIvMjQgMDU6Mzk6MTkgZGxnIEV4 cCAkCSovCisvKgkkT3BlbkJTRDogaWZfcGZzeW5jLmMsdiAxLjExMyAyMDA5LzAzLzAxIDEwOjM0 OjM4IGRsZyBFeHAgJAkqLwogCiAvKgogICogQ29weXJpZ2h0IChjKSAyMDAyIE1pY2hhZWwgU2hh bGF5ZWZmCkBAIC01OTAsOSArNTkxLDYgQEAKIHBmc3luY19pZl9kZXF1ZXVlKHN0cnVjdCBpZm5l dCAqaWZwKQogewogCXN0cnVjdCBtYnVmICptOwotI2lmbmRlZiBfX0ZyZWVCU0RfXwotCWludCBz OwotI2VuZGlmCiAKICNpZmRlZiBfX0ZyZWVCU0RfXwogCUlGX0xPQ0soJmlmcC0+aWZfc25kKTsK QEAgLTYwMCw5ICs1OTgsNyBAQAogCV9JRl9ERVFVRVVFKCZpZnAtPmlmX3NuZCwgbSk7CiAJSUZf VU5MT0NLKCZpZnAtPmlmX3NuZCk7CiAjZWxzZQotCXMgPSBzcGxuZXQoKTsKIAlJRl9ERVFVRVVF KCZpZnAtPmlmX3NuZCwgbSk7Ci0Jc3BseChzKTsKICNlbmRpZgogCiAJcmV0dXJuIChtKTsKQEAg LTYxNSwxMyArNjExLDE3IEBACiBwZnN5bmNzdGFydChzdHJ1Y3QgaWZuZXQgKmlmcCkKIHsKIAlz dHJ1Y3QgbWJ1ZiAqbTsKKwlpbnQgczsKIAorCXMgPSBzcGxuZXQoKTsKKwogCXdoaWxlICgobSA9 IHBmc3luY19pZl9kZXF1ZXVlKGlmcCkpICE9IE5VTEwpIHsKICNpZm5kZWYgX19GcmVlQlNEX18K IAkJSUZfRFJPUCgmaWZwLT5pZl9zbmQpOwogI2VuZGlmCiAJCW1fZnJlZW0obSk7CiAJfQorCXNw bHgocyk7CiB9CiAKIGludApAQCAtMTc4MCw3ICsxNzgwLDcgQEAKIAlzdHJ1Y3QgcGZzeW5jcmVx IHBmc3luY3I7CiAJc3RydWN0IGlmbmV0ICAgICpzaWZwOwogCXN0cnVjdCBpcCAqaXA7Ci0JaW50 IHMsIGVycm9yOworCWludCBlcnJvcjsKIAogCXN3aXRjaCAoY21kKSB7CiAjaWYgMApAQCAtMTgw NiwxNyArMTgwNiw4IEBACiAJCQlyZXR1cm4gKEVJTlZBTCk7CiAJCWlmIChpZnItPmlmcl9tdHUg PiBNQ0xCWVRFUykgLyogWFhYIGNvdWxkIGJlIGJpZ2dlciAqLwogCQkJaWZyLT5pZnJfbXR1ID0g TUNMQllURVM7Ci0JCWlmIChpZnItPmlmcl9tdHUgPCBpZnAtPmlmX210dSkgewotCQkJcyA9IHNw bG5ldCgpOwotI2lmZGVmIF9fRnJlZUJTRF9fCi0JCQlQRl9MT0NLKCk7Ci0jZW5kaWYKKwkJaWYg KGlmci0+aWZyX210dSA8IGlmcC0+aWZfbXR1KQogCQkJcGZzeW5jX3NlbmRvdXQoKTsKLSNpZmRl ZiBfX0ZyZWVCU0RfXwotCQkJUEZfVU5MT0NLKCk7Ci0jZW5kaWYKLQkJCXNwbHgocyk7Ci0JCX0K IAkJaWZwLT5pZl9tdHUgPSBpZnItPmlmcl9tdHU7CiAJCWJyZWFrOwogCWNhc2UgU0lPQ0dFVFBG U1lOQzoKQEAgLTE4ODMsMTAgKzE4NzQsNiBAQAogCQkJcmV0dXJuIChFSU5WQUwpOwogCiAjaWZk ZWYgX19GcmVlQlNEX18KLQkJUEZfTE9DSygpOwotI2VuZGlmCi0JCXMgPSBzcGxuZXQoKTsKLSNp ZmRlZiBfX0ZyZWVCU0RfXwogCQlpZiAoc2lmcC0+aWZfbXR1IDwgc2MtPnNjX2lmcC0+aWZfbXR1 IHx8CiAjZWxzZQogCQlpZiAoc2lmcC0+aWZfbXR1IDwgc2MtPnNjX2lmLmlmX210dSB8fApAQCAt MTg5OCwxMyArMTg4NSw3IEBACiAJCXNjLT5zY19zeW5jX2lmID0gc2lmcDsKIAogCQlpZiAoaW1v LT5pbW9fbnVtX21lbWJlcnNoaXBzID4gMCkgewotI2lmZGVmIF9fRnJlZUJTRF9fCi0JCQlQRl9V TkxPQ0soKTsKLSNlbmRpZgogCQkJaW5fZGVsbXVsdGkoaW1vLT5pbW9fbWVtYmVyc2hpcFstLWlt by0+aW1vX251bV9tZW1iZXJzaGlwc10pOwotI2lmZGVmIF9fRnJlZUJTRF9fCi0JCQlQRl9MT0NL KCk7Ci0jZW5kaWYKIAkJCWltby0+aW1vX211bHRpY2FzdF9pZnAgPSBOVUxMOwogCQl9CiAKQEAg LTE5MTgsMTAgKzE4OTksNiBAQAogCiAJCQlpZiAoIShzYy0+c2Nfc3luY19pZi0+aWZfZmxhZ3Mg JiBJRkZfTVVMVElDQVNUKSkgewogCQkJCXNjLT5zY19zeW5jX2lmID0gTlVMTDsKLSNpZmRlZiBf X0ZyZWVCU0RfXwotCQkJCVBGX1VOTE9DSygpOwotI2VuZGlmCi0JCQkJc3BseChzKTsKIAkJCQly ZXR1cm4gKEVBRERSTk9UQVZBSUwpOwogCQkJfQogCkBAIC0xOTMxLDE4ICsxOTA4LDExIEBACiAJ CQlhZGRyLnNfYWRkciA9IElOQUREUl9QRlNZTkNfR1JPVVA7CiAjZW5kaWYKIAotI2lmZGVmIF9f RnJlZUJTRF9fCi0JCQlQRl9VTkxPQ0soKTsKLSNlbmRpZgogCQkJaWYgKChpbW8tPmltb19tZW1i ZXJzaGlwWzBdID0KIAkJCSAgICBpbl9hZGRtdWx0aSgmYWRkciwgc2MtPnNjX3N5bmNfaWYpKSA9 PSBOVUxMKSB7CiAJCQkJc2MtPnNjX3N5bmNfaWYgPSBOVUxMOwotCQkJCXNwbHgocyk7CiAJCQkJ cmV0dXJuIChFTk9CVUZTKTsKIAkJCX0KLSNpZmRlZiBfX0ZyZWVCU0RfXwotCQkJUEZfTE9DSygp OwotI2VuZGlmCiAJCQlpbW8tPmltb19udW1fbWVtYmVyc2hpcHMrKzsKIAkJCWltby0+aW1vX211 bHRpY2FzdF9pZnAgPSBzYy0+c2Nfc3luY19pZjsKIAkJCWltby0+aW1vX211bHRpY2FzdF90dGwg PSBQRlNZTkNfREZMVFRMOwpAQCAtMTk5MywxMCArMTk2Myw2IEBACiAjZW5kaWYKIAkJCXBmc3lu Y19yZXF1ZXN0X3VwZGF0ZSgwLCAwKTsKIAkJfQotI2lmZGVmIF9fRnJlZUJTRF9fCi0JCVBGX1VO TE9DSygpOwotI2VuZGlmCi0JCXNwbHgocyk7CiAKIAkJYnJlYWs7CiAKQEAgLTIxNDIsMTIgKzIx MDgsNiBAQAogCWludCBvZmZzZXQ7CiAJaW50IHEsIGNvdW50ID0gMDsKIAotI2lmZGVmIF9fRnJl ZUJTRF9fCi0JUEZfQVNTRVJUKE1BX09XTkVEKTsKLSNlbHNlCi0Jc3BsYXNzZXJ0KElQTF9ORVQp OwotI2VuZGlmCi0KIAlpZiAoc2MgPT0gTlVMTCB8fCBzYy0+c2NfbGVuID09IFBGU1lOQ19NSU5Q S1QpCiAJCXJldHVybjsKIApAQCAtMjM0MiwyNyArMjMwMiwxMCBAQAogCXNjLT5zY19pZi5pZl9v Ynl0ZXMgKz0gbS0+bV9wa3RoZHIubGVuOwogI2VuZGlmCiAKLSNpZmRlZiBfX0ZyZWVCU0RfXwot CVBGX1VOTE9DSygpOwotI2VuZGlmCiAJaWYgKGlwX291dHB1dChtLCBOVUxMLCBOVUxMLCBJUF9S QVdPVVRQVVQsICZzYy0+c2NfaW1vLCBOVUxMKSA9PSAwKQotI2lmZGVmIF9fRnJlZUJTRF9fCi0J ewotCQlQRl9MT0NLKCk7Ci0jZW5kaWYKIAkJVl9wZnN5bmNzdGF0cy5wZnN5bmNzX29wYWNrZXRz Kys7Ci0jaWZkZWYgX19GcmVlQlNEX18KLQl9Ci0jZW5kaWYKIAllbHNlCi0jaWZkZWYgX19GcmVl QlNEX18KLQl7Ci0JCVBGX0xPQ0soKTsKLSNlbmRpZgogCQlWX3Bmc3luY3N0YXRzLnBmc3luY3Nf b2Vycm9ycysrOwotI2lmZGVmIF9fRnJlZUJTRF9fCi0JfQotI2VuZGlmCiAKIAkvKiBzdGFydCBh Z2FpbiAqLwogCXNjLT5zY19sZW4gPSBQRlNZTkNfTUlOUEtUOwpAQCAtMjQ3NCw3ICsyNDE3LDYg QEAKICNlbHNlCiAJc3RydWN0IHBmc3luY19zb2Z0YyAqc2MgPSBwZnN5bmNpZjsKICNlbmRpZgot CWludCBzOwogCiAjaWZkZWYgX19GcmVlQlNEX18KIAlQRl9BU1NFUlQoTUFfT1dORUQpOwpAQCAt MjQ5MCwxNyArMjQzMiw4IEBACiAJaWYgKGRyb3ApCiAJCW1fZnJlZW0ocGQtPnBkX20pOwogCWVs c2UgewotCQlzID0gc3BsbmV0KCk7Ci0jaWZkZWYgX19GcmVlQlNEX18KLQkJLyogWFhYOiB1c2Ug cGZfZGVmZXJlZD8hICovCi0JCVBGX1VOTE9DSygpOwotI2VuZGlmCiAJCWlwX291dHB1dChwZC0+ cGRfbSwgKHZvaWQgKilOVUxMLCAodm9pZCAqKU5VTEwsIDAsCiAJCSAgICAodm9pZCAqKU5VTEws ICh2b2lkICopTlVMTCk7Ci0jaWZkZWYgX19GcmVlQlNEX18KLQkJUEZfTE9DSygpOwotI2VuZGlm Ci0JCXNwbHgocyk7CiAJfQogCiAJcG9vbF9wdXQoJnNjLT5zY19wb29sLCBwZCk7CkBAIC0yNjIz LDcgKzI1NTYsNiBAQAogI2VuZGlmCiAJc3RydWN0IHBmc3luY191cGRfcmVxX2l0ZW0gKml0ZW07 CiAJc2l6ZV90IG5sZW4gPSBzaXplb2Yoc3RydWN0IHBmc3luY191cGRfcmVxKTsKLQlpbnQgczsK IAogCS8qCiAJICogdGhpcyBjb2RlIGRvZXMgbm90aGluZyB0byBwcmV2ZW50IG11bHRpcGxlIHVw ZGF0ZSByZXF1ZXN0cyBmb3IgdGhlCkBAIC0yNjQ3LDkgKzI1NzksNyBAQAogI2Vsc2UKIAlpZiAo c2MtPnNjX2xlbiArIG5sZW4gPiBzYy0+c2NfaWYuaWZfbXR1KSB7CiAjZW5kaWYKLQkJcyA9IHNw bG5ldCgpOwogCQlwZnN5bmNfc2VuZG91dCgpOwotCQlzcGx4KHMpOwogCiAJCW5sZW4gPSBzaXpl b2Yoc3RydWN0IHBmc3luY19zdWJoZWFkZXIpICsKIAkJICAgIHNpemVvZihzdHJ1Y3QgcGZzeW5j X3VwZF9yZXEpOwpAQCAtMjc5OSw3ICsyNzI5LDYgQEAKIAlzdHJ1Y3QgcGZzeW5jX3NvZnRjICpz YyA9IHBmc3luY2lmOwogI2VuZGlmCiAJc2l6ZV90IG5sZW4gPSBwZnN5bmNfcXNbcV0ubGVuOwot CWludCBzOwogCiAjaWZkZWYgX19GcmVlQlNEX18KIAlLQVNTRVJUKHN0LT5zeW5jX3N0YXRlID09 IFBGU1lOQ19TX05PTkUsCkBAIC0yODI0LDE1ICsyNzUzLDcgQEAKICNlbHNlCiAJaWYgKHNjLT5z Y19sZW4gKyBubGVuID4gc2MtPnNjX2lmLmlmX210dSkgewogI2VuZGlmCi0JCXMgPSBzcGxuZXQo KTsKLSNpZmRlZiBfX0ZyZWVCU0RfXwotCQlQRl9MT0NLKCk7Ci0jZW5kaWYKIAkJcGZzeW5jX3Nl bmRvdXQoKTsKLSNpZmRlZiBfX0ZyZWVCU0RfXwotCQlQRl9VTkxPQ0soKTsKLSNlbmRpZgotCQlz cGx4KHMpOwogCiAJCW5sZW4gPSBzaXplb2Yoc3RydWN0IHBmc3luY19zdWJoZWFkZXIpICsgcGZz eW5jX3FzW3FdLmxlbjsKIAl9CkBAIC0yODc3LDcgKzI3OTgsNiBAQAogCXN0cnVjdCBwZnN5bmNf c29mdGMgKnNjID0gcGZzeW5jaWY7CiAjZW5kaWYKIAlzaXplX3QgbmxlbiA9IHNpemVvZihzdHJ1 Y3QgcGZzeW5jX3RkYik7Ci0JaW50IHM7CiAKIAlpZiAoc2MgPT0gTlVMTCkKIAkJcmV0dXJuOwpA QCAtMjg4Nyw5ICsyODA3LDcgQEAKIAkJCW5sZW4gKz0gc2l6ZW9mKHN0cnVjdCBwZnN5bmNfc3Vi aGVhZGVyKTsKIAogCQlpZiAoc2MtPnNjX2xlbiArIG5sZW4gPiBzYy0+c2NfaWYuaWZfbXR1KSB7 Ci0JCQlzID0gc3BsbmV0KCk7CiAJCQlwZnN5bmNfc2VuZG91dCgpOwotCQkJc3BseChzKTsKIAog CQkJbmxlbiA9IHNpemVvZihzdHJ1Y3QgcGZzeW5jX3N1YmhlYWRlcikgKwogCQkJICAgIHNpemVv ZihzdHJ1Y3QgcGZzeW5jX3RkYik7CkBAIC0zMTM3LDM2ICszMDU1LDE4IEBACiAjZWxzZQogCXN0 cnVjdCBwZnN5bmNfc29mdGMgKnNjID0gcGZzeW5jaWY7CiAjZW5kaWYKLQlpbnQgczsKIAogI2lm ZGVmIF9fRnJlZUJTRF9fCi0JaWYgKHNjLT5zY19sZW4gKyBwbHVzbGVuID4gc2MtPnNjX2lmcC0+ aWZfbXR1KSB7CisJaWYgKHNjLT5zY19sZW4gKyBwbHVzbGVuID4gc2MtPnNjX2lmcC0+aWZfbXR1 KQogI2Vsc2UKLQlpZiAoc2MtPnNjX2xlbiArIHBsdXNsZW4gPiBzYy0+c2NfaWYuaWZfbXR1KSB7 CisJaWYgKHNjLT5zY19sZW4gKyBwbHVzbGVuID4gc2MtPnNjX2lmLmlmX210dSkKICNlbmRpZgot CQlzID0gc3BsbmV0KCk7Ci0jaWZkZWYgX19GcmVlQlNEX18KLQkJUEZfTE9DSygpOwotI2VuZGlm CiAJCXBmc3luY19zZW5kb3V0KCk7Ci0jaWZkZWYgX19GcmVlQlNEX18KLQkJUEZfVU5MT0NLKCk7 Ci0jZW5kaWYKLQkJc3BseChzKTsKLQl9CiAKIAlzYy0+c2NfcGx1cyA9IHBsdXM7CiAJc2MtPnNj X2xlbiArPSAoc2MtPnNjX3BsdXNsZW4gPSBwbHVzbGVuKTsKIAotCXMgPSBzcGxuZXQoKTsKLSNp ZmRlZiBfX0ZyZWVCU0RfXwotCVBGX0xPQ0soKTsKLSNlbmRpZgogCXBmc3luY19zZW5kb3V0KCk7 Ci0jaWZkZWYgX19GcmVlQlNEX18KLQlQRl9VTkxPQ0soKTsKLSNlbmRpZgotCXNwbHgocyk7CiB9 CiAKIGludApAQCAtMzIwOSw5ICszMTA5LDYgQEAKIAlyZXR1cm4gKDEpOwogfQogCi11X2ludCBw ZnN5bmNfaW50czsKLXVfaW50IHBmc3luY190bW9zOwotCiB2b2lkCiBwZnN5bmNfdGltZW91dCh2 b2lkICphcmcpCiB7CkBAIC0zMjI0LDE2ICszMTIxLDggQEAKIAlDVVJWTkVUX1NFVChzYy0+c2Nf aWZwLT5pZl92bmV0KTsKICNlbmRpZgogCi0JcGZzeW5jX3Rtb3MrKzsKLQotCXMgPSBzcGxuZXQo KTsKLSNpZmRlZiBfX0ZyZWVCU0RfXwotCVBGX0xPQ0soKTsKLSNlbmRpZgorCXMgPSBzcGxzb2Z0 bmV0KCk7CiAJcGZzeW5jX3NlbmRvdXQoKTsKLSNpZmRlZiBfX0ZyZWVCU0RfXwotCVBGX1VOTE9D SygpOwotI2VuZGlmCiAJc3BseChzKTsKIAogI2lmZGVmIF9fRnJlZUJTRF9fCkBAIC0zMjUxLDI2 ICszMTQwLDE0IEBACiB7CiAjaWZkZWYgX19GcmVlQlNEX18KIAlzdHJ1Y3QgcGZzeW5jX3NvZnRj ICpzYyA9IGFyZzsKLSNlbmRpZgotCWludCBzOwogCi0jaWZkZWYgX19GcmVlQlNEX18KIAlpZiAo c2MgPT0gTlVMTCkKIAkJcmV0dXJuOwogCiAJQ1VSVk5FVF9TRVQoc2MtPnNjX2lmcC0+aWZfdm5l dCk7CiAjZW5kaWYKLQlwZnN5bmNfaW50cysrOwogCi0JcyA9IHNwbG5ldCgpOwotI2lmZGVmIF9f RnJlZUJTRF9fCi0JUEZfTE9DSygpOwotI2VuZGlmCiAJcGZzeW5jX3NlbmRvdXQoKTsKLSNpZmRl ZiBfX0ZyZWVCU0RfXwotCVBGX1VOTE9DSygpOwotI2VuZGlmCi0Jc3BseChzKTsKIAogI2lmZGVm IF9fRnJlZUJTRF9fCiAJQ1VSVk5FVF9SRVNUT1JFKCk7Cg== --000e0cd4c08e974e9704a7f99174-- From owner-freebsd-net@FreeBSD.ORG Thu Jul 14 01:54:20 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CDC21065674; Thu, 14 Jul 2011 01:54:20 +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 13A5E8FC0C; Thu, 14 Jul 2011 01:54:20 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6E1sJTL021512; Thu, 14 Jul 2011 01:54:19 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6E1sJB3021508; Thu, 14 Jul 2011 01:54:19 GMT (envelope-from linimon) Date: Thu, 14 Jul 2011 01:54:19 GMT Message-Id: <201107140154.p6E1sJB3021508@freefall.freebsd.org> To: stepanvv@gmail.com, linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/138029: [bpf] [panic] periodically kernel panic and reboot 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 Jul 2011 01:54:20 -0000 Old Synopsis: [panic][bpf] periodically kernel panic and reboot New Synopsis: [bpf] [panic] periodically kernel panic and reboot State-Changed-From-To: open->feedback State-Changed-By: linimon State-Changed-When: Thu Jul 14 01:53:36 UTC 2011 State-Changed-Why: Most likely not amd64-specific. To submitter: is this still a problem? Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jul 14 01:53:36 UTC 2011 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=138029 From owner-freebsd-net@FreeBSD.ORG Thu Jul 14 01:55:03 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30B861065670; Thu, 14 Jul 2011 01:55:03 +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 024498FC20; Thu, 14 Jul 2011 01:55:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6E1t2J5021580; Thu, 14 Jul 2011 01:55:02 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6E1t2KV021576; Thu, 14 Jul 2011 01:55:02 GMT (envelope-from linimon) Date: Thu, 14 Jul 2011 01:55:02 GMT Message-Id: <201107140155.p6E1t2KV021576@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/158880: [bpf] bpf_filter() can leak kernel stack contents 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 Jul 2011 01:55:03 -0000 Old Synopsis: bpf_filter() can leak kernel stack contents New Synopsis: [bpf] bpf_filter() can leak kernel stack contents Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jul 14 01:54:35 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=158880 From owner-freebsd-net@FreeBSD.ORG Thu Jul 14 01:56:07 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26FB8106564A; Thu, 14 Jul 2011 01:56:07 +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 F39CB8FC19; Thu, 14 Jul 2011 01:56:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6E1u6BH021654; Thu, 14 Jul 2011 01:56:06 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6E1u6lm021650; Thu, 14 Jul 2011 01:56:06 GMT (envelope-from linimon) Date: Thu, 14 Jul 2011 01:56:06 GMT Message-Id: <201107140156.p6E1u6lm021650@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-pf@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/158873: [pf] [panic] When I launch pf daemon, I have a kernel panic 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 Jul 2011 01:56:07 -0000 Old Synopsis: When I launch pf daemon, I have a kernel panic New Synopsis: [pf] [panic] When I launch pf daemon, I have a kernel panic Responsible-Changed-From-To: freebsd-net->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jul 14 01:55:42 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=158873 From owner-freebsd-net@FreeBSD.ORG Thu Jul 14 04:22:24 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF80C1065675; Thu, 14 Jul 2011 04:22:24 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A75AB8FC1F; Thu, 14 Jul 2011 04:22:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6E4MOaB058105; Thu, 14 Jul 2011 04:22:24 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6E4MOQT058101; Thu, 14 Jul 2011 04:22:24 GMT (envelope-from ae) Date: Thu, 14 Jul 2011 04:22:24 GMT Message-Id: <201107140422.p6E4MOQT058101@freefall.freebsd.org> To: aboyer@averesystems.com, ae@FreeBSD.org, freebsd-net@FreeBSD.org From: ae@FreeBSD.org Cc: Subject: Re: kern/154831: [arp] [patch] arp sysctl setting log_arp_permanent_modify has no effect 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 Jul 2011 04:22:24 -0000 Synopsis: [arp] [patch] arp sysctl setting log_arp_permanent_modify has no effect State-Changed-From-To: patched->closed State-Changed-By: ae State-Changed-When: Thu Jul 14 04:21:55 UTC 2011 State-Changed-Why: Merged to stable/8. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=154831 From owner-freebsd-net@FreeBSD.ORG Thu Jul 14 04:30:15 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93E551065674 for ; Thu, 14 Jul 2011 04:30:15 +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 846B18FC08 for ; Thu, 14 Jul 2011 04:30:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6E4UFj1058449 for ; Thu, 14 Jul 2011 04:30:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6E4UFmt058446; Thu, 14 Jul 2011 04:30:15 GMT (envelope-from gnats) Date: Thu, 14 Jul 2011 04:30:15 GMT Message-Id: <201107140430.p6E4UFmt058446@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/154831: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 04:30:15 -0000 The following reply was made to PR kern/154831; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/154831: commit references a PR Date: Thu, 14 Jul 2011 04:21:36 +0000 (UTC) Author: ae Date: Thu Jul 14 04:21:27 2011 New Revision: 223995 URL: http://svn.freebsd.org/changeset/base/223995 Log: MFC r223840: Add again the checking for log_arp_permanent_modify that was by accident removed in the r186119. PR: kern/154831 Modified: stable/8/sys/netinet/if_ether.c Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) Modified: stable/8/sys/netinet/if_ether.c ============================================================================== --- stable/8/sys/netinet/if_ether.c Thu Jul 14 03:16:43 2011 (r223994) +++ stable/8/sys/netinet/if_ether.c Thu Jul 14 04:21:27 2011 (r223995) @@ -680,11 +680,13 @@ match: bcmp(ar_sha(ah), &la->ll_addr, ifp->if_addrlen)) { if (la->la_flags & LLE_STATIC) { LLE_WUNLOCK(la); - log(LOG_ERR, - "arp: %*D attempts to modify permanent " - "entry for %s on %s\n", - ifp->if_addrlen, (u_char *)ar_sha(ah), ":", - inet_ntoa(isaddr), ifp->if_xname); + if (log_arp_permanent_modify) + log(LOG_ERR, + "arp: %*D attempts to modify " + "permanent entry for %s on %s\n", + ifp->if_addrlen, + (u_char *)ar_sha(ah), ":", + inet_ntoa(isaddr), ifp->if_xname); goto reply; } if (log_arp_movements) { _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Jul 14 07:02:01 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9440106564A; Thu, 14 Jul 2011 07:02:01 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9250A8FC12; Thu, 14 Jul 2011 07:02:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6E721jj012327; Thu, 14 Jul 2011 07:02:01 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6E721Y4012318; Thu, 14 Jul 2011 07:02:01 GMT (envelope-from ae) Date: Thu, 14 Jul 2011 07:02:01 GMT Message-Id: <201107140702.p6E721Y4012318@freefall.freebsd.org> To: ae@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-wireless@FreeBSD.org From: ae@FreeBSD.org Cc: Subject: Re: kern/155498: [ral] ral(4) needs to be resynced with OpenBSD's to gain RT2860/2870 support. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 07:02:01 -0000 Synopsis: [ral] ral(4) needs to be resynced with OpenBSD's to gain RT2860/2870 support. Responsible-Changed-From-To: freebsd-net->freebsd-wireless Responsible-Changed-By: ae Responsible-Changed-When: Thu Jul 14 07:00:44 UTC 2011 Responsible-Changed-Why: Reassign to wireless team. http://www.freebsd.org/cgi/query-pr.cgi?pr=155498 From owner-freebsd-net@FreeBSD.ORG Thu Jul 14 15:44:59 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24DAF106566C; Thu, 14 Jul 2011 15:44:59 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id B4C088FC1B; Thu, 14 Jul 2011 15:44:58 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.4/8.14.4) with ESMTP id p6EFivqa017624; Thu, 14 Jul 2011 19:44:57 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.4/8.14.4/Submit) id p6EFivoe017623; Thu, 14 Jul 2011 19:44:57 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 14 Jul 2011 19:44:57 +0400 From: Gleb Smirnoff To: bz@FreeBSD.org, rwatson@FreeBSD.org, gnn@FreeBSD.org Message-ID: <20110714154457.GI70776@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: net@FreeBSD.org Subject: m_pkthdr.rcvif dangling pointer problem 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 Jul 2011 15:44:59 -0000 Hi! This problem is definitely known and is as old as network stack is parallel. Those, who know the problem may skip to next paragraph. Short description is the following: every mbuf that is allocated in an interface receive procedure has a field where a pointer to the corresponding struct ifnet is stored. Everything is okay, until you are running a box, where configuration of interfaces is changing rapidly, for example a PPP access concentrator. Utilizing any facility that can delay packet processing for example netgraph(4) or dummynet(4) would make probability of crash much bigger. Running INVARIANTS kernel would crash a box with dummynet and disappearing interfaces in a few minutes. I see three approaches to this problem: 1) Every m_pkthdr.rcvif should if_ref() the interface. Releasing references can be done in the mbuf allocator: mb_dtor_mbuf(), mb_dtor_pack(). I'm afraid this approach would degrate performance, since adding at least a couple of atomic ops on every mbuf for its lifetime. That is +2 atomic ops per packet. 2) kib@ suggested to allocate ifnets from a UMA_ZONE_NOFREE zone. I've made a compilable & working patch: http://people.freebsd.org/~glebius/patches/ifnet.no_free But on second though I find this a bad idea, this is just fooling of INVARIANTS. Yes, we avoid thrashing of freed memory and rewriting it by some other kernel allocation. But still out pointer point to invalid ifnet. Even, if we make a check for IFF_DYING flag, we still can not guarantee that an interface had been re-allocated for a new instance. This would be not a panic condition, but subtle bugs in firewalls. 3) As we now have a straight if_index table that can grow, what about storing the if_index in the m_pkthdr? Lookup of interface by index is fast enough if done lockless. Doing it lockless isn't perfect, but better than current pointer dereferncing. Optionally it could be done with locking and with putting a reference. To avoid situation with with getting to a re-allocated interface with the same index, we can use a unique cookie, that is incremented in if_alloc(). Smth like: struct ifnet * mbuf_rcvif(struct mbuf *m) { struct ifnet *ifp; M_ASSERTPKTHDR(m); if (m->m_pkthdr.rcvif_idx == 0) return (NULL); ifp = ifnet_byindex_locked(m->m_pkthdr.rcvif_idx); if (ifp == NULL) return (NULL); if (ifp->if_unique != m->m_pkthdr.rcvif_unique) return (NULL); return (ifp); } struct ifnet * mbuf_rcvif_ref(struct mbuf *m) { struct ifnet *ifp; M_ASSERTPKTHDR(m); if (m->m_pkthdr.rcvif_idx == 0) return (NULL); ifp = ifnet_byindex_ref(m->m_pkthdr.rcvif_idx); if (ifp == NULL) return (NULL); if (ifp->if_unique != m->m_pkthdr.rcvif_unique) { if_rele(ifp); return (NULL); } return (ifp); } The size of struct mbuf isn't going to change on amd64: @@ -111,7 +111,8 @@ * Record/packet header in first mbuf of chain; valid only if M_PKTHDR is set. */ struct pkthdr { - struct ifnet *rcvif; /* rcv interface */ + uint32_t rcvif_idx; /* rcv interface index */ + uint32_t rcvif_unique; /* rcv interface unique id */ A proof-of-concept patch is available here: http://people.freebsd.org/~glebius/patches/pkthdr.rcvif_idx It doesn't cover entire kernel, LINT won't compile. It covers kern, netinet, netinet6, several interface drivers and netgraph. One of the problems is ongoing namespace pollution: not all code that include mbuf.h includes if_var.h and vice versa. I've cut ifnet from m_devget(), but my new function do declare it in parameter list :(. To deal with that I had to declare functions in mbuf.h but implement them in if.c. Other problem is net80211 code that abuses the rcvif pointer in mbuf packet header for its own purposes casting it to private type. This can be fixed utilizing mbuf_tags(9), I think. I haven't made this yet, that's why LINT doesn't compile. Comments are requested! Any alternative ideas on solving the problem are welcome! -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Thu Jul 14 16:38:58 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AF5C106564A; Thu, 14 Jul 2011 16:38:58 +0000 (UTC) (envelope-from mp@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 240448FC08; Thu, 14 Jul 2011 16:38:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6EGcwYq066841; Thu, 14 Jul 2011 16:38:58 GMT (envelope-from mp@freefall.freebsd.org) Received: (from mp@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6EGcvk6066837; Thu, 14 Jul 2011 16:38:58 GMT (envelope-from mp) Date: Thu, 14 Jul 2011 16:38:58 GMT Message-Id: <201107141638.p6EGcvk6066837@freefall.freebsd.org> To: mp@FreeBSD.org, freebsd-net@FreeBSD.org, mp@FreeBSD.org From: mp@FreeBSD.org Cc: Subject: Re: kern/158880: [bpf] bpf_filter() can leak kernel stack contents 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 Jul 2011 16:38:58 -0000 Synopsis: [bpf] bpf_filter() can leak kernel stack contents Responsible-Changed-From-To: freebsd-net->mp@FreeBSD.org Responsible-Changed-By: mp Responsible-Changed-When: Thu Jul 14 16:36:38 UTC 2011 Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=158880 From owner-freebsd-net@FreeBSD.ORG Thu Jul 14 17:54:54 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70A79106566C for ; Thu, 14 Jul 2011 17:54:54 +0000 (UTC) (envelope-from prvs=1176c4cfda=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id ED4988FC1E for ; Thu, 14 Jul 2011 17:54:53 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Thu, 14 Jul 2011 18:40:50 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 14 Jul 2011 18:40:50 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50014154375.msg for ; Thu, 14 Jul 2011 18:40:50 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1176c4cfda=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <1C7400B2BB7D496FB64663C99D119F31@multiplay.co.uk> From: "Steven Hartland" To: Date: Thu, 14 Jul 2011 18:41:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Subject: ifconfig idg1 down delete fails with ipv6 enabled 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 Jul 2011 17:54:54 -0000 When trying to clear down an interface in this case igb1 I usually just use:- ifconfig down delete This seems to fail when ipv6 is enabled on 8.2-RELEASE where I get ifconfig igb1 down delete ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address This a bug? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Thu Jul 14 19:25:08 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 736E4106566B for ; Thu, 14 Jul 2011 19:25:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id BC3208FC0A for ; Thu, 14 Jul 2011 19:25:07 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p6EIp0ux068669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jul 2011 21:51:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p6EIp0Qi012397; Thu, 14 Jul 2011 21:51:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p6EIp0Yg012396; Thu, 14 Jul 2011 21:51:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Jul 2011 21:51:00 +0300 From: Kostik Belousov To: Gleb Smirnoff Message-ID: <20110714185100.GC43872@deviant.kiev.zoral.com.ua> References: <20110714154457.GI70776@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dmVtbNsdrXqYZXhl" Content-Disposition: inline In-Reply-To: <20110714154457.GI70776@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: gnn@freebsd.org, bz@freebsd.org, rwatson@freebsd.org, net@freebsd.org Subject: Re: m_pkthdr.rcvif dangling pointer problem 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 Jul 2011 19:25:08 -0000 --dmVtbNsdrXqYZXhl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 14, 2011 at 07:44:57PM +0400, Gleb Smirnoff wrote: > Hi! >=20 > This problem is definitely known and is as old as network stack > is parallel. Those, who know the problem may skip to next paragraph. > Short description is the following: every mbuf that is allocated in > an interface receive procedure has a field where a pointer to the > corresponding struct ifnet is stored. Everything is okay, until you > are running a box, where configuration of interfaces is changing > rapidly, for example a PPP access concentrator. Utilizing any facility > that can delay packet processing for example netgraph(4) or dummynet(4) > would make probability of crash much bigger. Running INVARIANTS kernel > would crash a box with dummynet and disappearing interfaces in a few > minutes. >=20 > I see three approaches to this problem: >=20 > 1) Every m_pkthdr.rcvif should if_ref() the interface. Releasing > references can be done in the mbuf allocator: mb_dtor_mbuf(), > mb_dtor_pack(). I'm afraid this approach would degrate performance, > since adding at least a couple of atomic ops on every mbuf for its > lifetime. That is +2 atomic ops per packet. >=20 > 2) kib@ suggested to allocate ifnets from a UMA_ZONE_NOFREE zone. > I've made a compilable & working patch: >=20 > http://people.freebsd.org/~glebius/patches/ifnet.no_free >=20 > But on second though I find this a bad idea, this is just fooling > of INVARIANTS. Yes, we avoid thrashing of freed memory and rewriting > it by some other kernel allocation. But still out pointer point to > invalid ifnet. Even, if we make a check for IFF_DYING flag, we still > can not guarantee that an interface had been re-allocated for a new > instance. This would be not a panic condition, but subtle bugs in > firewalls. This is not quite what I suggested (not looking at the patch). I also noted that some measures to prevent the dereference of outdated pointers should be taken. We discussed the generation counter for the ifnets, and I pointed out that m_hdr has at least two MI scratch bytes. Also, on amd64, there seems to be one spare word in pkthdr dur to alignment. >=20 > 3) As we now have a straight if_index table that can grow, what about > storing the if_index in the m_pkthdr? Lookup of interface by index > is fast enough if done lockless. Doing it lockless isn't perfect, but > better than current pointer dereferncing. Optionally it could be > done with locking and with putting a reference. To avoid situation > with with getting to a re-allocated interface with the same index, > we can use a unique cookie, that is incremented in if_alloc(). > Smth like: >=20 > struct ifnet *=20 > mbuf_rcvif(struct mbuf *m) > { > struct ifnet *ifp; > =20 > M_ASSERTPKTHDR(m); >=20 > if (m->m_pkthdr.rcvif_idx =3D=3D 0) > return (NULL); >=20 > ifp =3D ifnet_byindex_locked(m->m_pkthdr.rcvif_idx); > if (ifp =3D=3D NULL) > return (NULL); > if (ifp->if_unique !=3D m->m_pkthdr.rcvif_unique) > return (NULL); >=20 > return (ifp); =20 > } >=20 > struct ifnet * > mbuf_rcvif_ref(struct mbuf *m) > { > struct ifnet *ifp; >=20 > M_ASSERTPKTHDR(m); >=20 > if (m->m_pkthdr.rcvif_idx =3D=3D 0) > return (NULL); >=20 > ifp =3D ifnet_byindex_ref(m->m_pkthdr.rcvif_idx); > if (ifp =3D=3D NULL) > return (NULL); > if (ifp->if_unique !=3D m->m_pkthdr.rcvif_unique) { > if_rele(ifp); > return (NULL); > } >=20 > return (ifp); > } >=20 > The size of struct mbuf isn't going to change on amd64: >=20 > @@ -111,7 +111,8 @@ > * Record/packet header in first mbuf of chain; valid only if M_PKTHDR i= s set. > */ > struct pkthdr { > - struct ifnet *rcvif; /* rcv interface */ > + uint32_t rcvif_idx; /* rcv interface index */ > + uint32_t rcvif_unique; /* rcv interface unique id */ >=20 > A proof-of-concept patch is available here: >=20 > http://people.freebsd.org/~glebius/patches/pkthdr.rcvif_idx >=20 > It doesn't cover entire kernel, LINT won't compile. It covers kern, netin= et, > netinet6, several interface drivers and netgraph. >=20 > One of the problems is ongoing namespace pollution: not all code that inc= lude > mbuf.h includes if_var.h and vice versa. I've cut ifnet from m_devget(), = but > my new function do declare it in parameter list :(. To deal with that I h= ad > to declare functions in mbuf.h but implement them in if.c. >=20 > Other problem is net80211 code that abuses the rcvif pointer in mbuf pack= et > header for its own purposes casting it to private type. This can be fixed > utilizing mbuf_tags(9), I think. I haven't made this yet, that's why LINT > doesn't compile. >=20 > Comments are requested! >=20 > Any alternative ideas on solving the problem are welcome! >=20 > --=20 > Totus tuus, Glebius. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --dmVtbNsdrXqYZXhl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4fOpQACgkQC3+MBN1Mb4hp9ACgslS4Th8L+s8f8gloH/F2sxG0 Y8MAn0JDKZ6d64Sh0HuBHltdMBS2kcza =a3yG -----END PGP SIGNATURE----- --dmVtbNsdrXqYZXhl-- From owner-freebsd-net@FreeBSD.ORG Fri Jul 15 00:49:52 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 949C8106564A; Fri, 15 Jul 2011 00:49:52 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate.funkthat.com [70.36.235.232]) by mx1.freebsd.org (Postfix) with ESMTP id 666D68FC15; Fri, 15 Jul 2011 00:49:52 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id p6F0R2eg060439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jul 2011 17:27:02 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id p6F0R2nO060438; Thu, 14 Jul 2011 17:27:02 -0700 (PDT) (envelope-from jmg) Date: Thu, 14 Jul 2011 17:27:01 -0700 From: John-Mark Gurney To: Gleb Smirnoff Message-ID: <20110715002701.GH1822@funkthat.com> Mail-Followup-To: Gleb Smirnoff , bz@freebsd.org, rwatson@freebsd.org, gnn@freebsd.org, net@freebsd.org References: <20110714154457.GI70776@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110714154457.GI70776@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 14 Jul 2011 17:27:02 -0700 (PDT) Cc: gnn@freebsd.org, bz@freebsd.org, rwatson@freebsd.org, net@freebsd.org Subject: Re: m_pkthdr.rcvif dangling pointer problem 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 Jul 2011 00:49:52 -0000 Gleb Smirnoff wrote this message on Thu, Jul 14, 2011 at 19:44 +0400: > 2) kib@ suggested to allocate ifnets from a UMA_ZONE_NOFREE zone. > I've made a compilable & working patch: > > http://people.freebsd.org/~glebius/patches/ifnet.no_free > > But on second though I find this a bad idea, this is just fooling > of INVARIANTS. Yes, we avoid thrashing of freed memory and rewriting > it by some other kernel allocation. But still out pointer point to > invalid ifnet. Even, if we make a check for IFF_DYING flag, we still > can not guarantee that an interface had been re-allocated for a new > instance. This would be not a panic condition, but subtle bugs in > firewalls. > > 3) As we now have a straight if_index table that can grow, what about > storing the if_index in the m_pkthdr? Lookup of interface by index > is fast enough if done lockless. Doing it lockless isn't perfect, but > better than current pointer dereferncing. Optionally it could be > done with locking and with putting a reference. To avoid situation > with with getting to a re-allocated interface with the same index, > we can use a unique cookie, that is incremented in if_alloc(). How is this any different than #2? I assume that if_index's are reused causing the same issues w/ the firewall that #2 has. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Fri Jul 15 04:45:28 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E43451065670; Fri, 15 Jul 2011 04:45:28 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BD4968FC12; Fri, 15 Jul 2011 04:45:28 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6F4jS54034363; Fri, 15 Jul 2011 04:45:28 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6F4jS0j034359; Fri, 15 Jul 2011 04:45:28 GMT (envelope-from linimon) Date: Fri, 15 Jul 2011 04:45:28 GMT Message-Id: <201107150445.p6F4jS0j034359@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/158930: [bpf] BPF element leak in ifp->bpf_if->bif_dlist 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 Jul 2011 04:45:29 -0000 Old Synopsis: BPF element leak in ifp->bpf_if->bif_dlist New Synopsis: [bpf] BPF element leak in ifp->bpf_if->bif_dlist Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jul 15 04:44:31 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=158930 From owner-freebsd-net@FreeBSD.ORG Fri Jul 15 06:53:42 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82DB4106564A; Fri, 15 Jul 2011 06:53:42 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 0C8C48FC0C; Fri, 15 Jul 2011 06:53:41 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.4/8.14.4) with ESMTP id p6F6re6R023275; Fri, 15 Jul 2011 10:53:40 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.4/8.14.4/Submit) id p6F6rep1023274; Fri, 15 Jul 2011 10:53:40 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 15 Jul 2011 10:53:40 +0400 From: Gleb Smirnoff To: bz@FreeBSD.org, rwatson@FreeBSD.org, gnn@FreeBSD.org, net@FreeBSD.org Message-ID: <20110715065340.GK70776@glebius.int.ru> References: <20110714154457.GI70776@FreeBSD.org> <20110715002701.GH1822@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20110715002701.GH1822@funkthat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: m_pkthdr.rcvif dangling pointer problem 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 Jul 2011 06:53:42 -0000 On Thu, Jul 14, 2011 at 05:27:01PM -0700, John-Mark Gurney wrote: J> Gleb Smirnoff wrote this message on Thu, Jul 14, 2011 at 19:44 +0400: J> > 2) kib@ suggested to allocate ifnets from a UMA_ZONE_NOFREE zone. J> > I've made a compilable & working patch: J> > J> > http://people.freebsd.org/~glebius/patches/ifnet.no_free J> > J> > But on second though I find this a bad idea, this is just fooling J> > of INVARIANTS. Yes, we avoid thrashing of freed memory and rewriting J> > it by some other kernel allocation. But still out pointer point to J> > invalid ifnet. Even, if we make a check for IFF_DYING flag, we still J> > can not guarantee that an interface had been re-allocated for a new J> > instance. This would be not a panic condition, but subtle bugs in J> > firewalls. J> > J> > 3) As we now have a straight if_index table that can grow, what about J> > storing the if_index in the m_pkthdr? Lookup of interface by index J> > is fast enough if done lockless. Doing it lockless isn't perfect, but J> > better than current pointer dereferncing. Optionally it could be J> > done with locking and with putting a reference. To avoid situation J> > with with getting to a re-allocated interface with the same index, J> > we can use a unique cookie, that is incremented in if_alloc(). J> J> How is this any different than #2? I assume that if_index's are reused J> causing the same issues w/ the firewall that #2 has. See last sentence: to avoid this situation we also store an interface cookie. Index for fast lookup. Cookie to check that this is the same interface. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Jul 15 16:58:43 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FB031065673 for ; Fri, 15 Jul 2011 16:58:43 +0000 (UTC) (envelope-from prvs=11774c4b74=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 524AA8FC19 for ; Fri, 15 Jul 2011 16:58:42 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Fri, 15 Jul 2011 17:47:18 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 15 Jul 2011 17:47:18 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50014168297.msg for ; Fri, 15 Jul 2011 17:47:18 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=11774c4b74=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <379885BA631F4C7787C24E00A174B429@multiplay.co.uk> From: "Steven Hartland" To: Date: Fri, 15 Jul 2011 17:47:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Subject: igb enable_aim or flow_control causing tcp stalls? 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 Jul 2011 16:58:43 -0000 Been trying to identify an strange network stalling issue while using scp or rsync between two machines, initially at remote locations. The behaviour has proved quite difficult to track as it seems to require a number or factors combined before the stalls occur. These seem to be: 1. This particular target machine 2. Some load, but not much on the machine, when idle we don't see stalls. 3. Remote 9ms+ latency or high through put 50MB/s transmission speeds My current test case is copying a freebsd iso from a local machine to the potentially problematic machine's /dev/null e.g. scp FreeBSD-8.2-RELEASE-amd64-disc1.iso test1:/dev/null These machines are connected via a cisco 6509 -> supermicro blade chassis. When the failure happens we see the following:- scp FreeBSD-8.2-RELEASE-amd64-disc1.iso amsbld16:/dev/null FreeBSD-8.2-RELEASE-amd64-disc1.iso 21% 147MB 2.1MB/s - stalled - When all is well we see:- scp FreeBSD-8.2-RELEASE-amd64-disc1.iso amsbld16:/dev/null FreeBSD-8.2-RELEASE-amd64-disc1.iso 100% 691MB 53.1MB/s 00:13 This setup:- 1. Source machine 7.0-RELEASE-p2 using em0 em0@pci0:6:0:0: class=0x020000 card=0x109615d9 chip=0x10968086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 EB Network Connection' class = network subclass = ethernet 2. Target (problem) machine 8.2-RELEASE using igb0 igb0@pci0:5:0:0: class=0x020000 card=0x10e715d9 chip=0x10e78086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet I've tried switching to igb1 with no change, which also changes switches and hence ports on the Cisco, so I don't at this point believe there is an issue there. Now I've just noticed that igb has at least two sysctl's which seemed interesting, enable_aim & flow_control (which is missing from the man page btw). On disabling both, the stalls seem to go away. Unfortunately re-enabling them didn't re-introduce the stalls, but this could another quirk when they don't re-enable properly? So the questions are:- 1. Could either of these settings cause tcp stalls? 2. If the nic and switch differ in flow control, what is the likely effect? 3. Any other thoughts? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Fri Jul 15 17:28:26 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE9FE1065674 for ; Fri, 15 Jul 2011 17:28:26 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8CF5C8FC18 for ; Fri, 15 Jul 2011 17:28:26 +0000 (UTC) Received: by gwb15 with SMTP id 15so764775gwb.13 for ; Fri, 15 Jul 2011 10:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Rg4gfujDVlmaz3ibzyBKTML0zy/APid2vAjjX2hqxzM=; b=V/H6sYp/opxurdW+VwIFlcfz0rm3HKRymX4jNyFXt8JqCGKZi7TJHsebmVxSwPkLU5 8Z6r41kB8Qd5skCEMxxbWB5HURMMlnTxk34safdDkcb/FC9AlZvPvduZlHzImYZXuaBY SbUJx/2g214UYu4tbnIasEhXtjaqcmfF+/6i8= MIME-Version: 1.0 Received: by 10.151.51.7 with SMTP id d7mr2654821ybk.426.1310750905733; Fri, 15 Jul 2011 10:28:25 -0700 (PDT) Received: by 10.151.27.21 with HTTP; Fri, 15 Jul 2011 10:28:24 -0700 (PDT) Received: by 10.151.27.21 with HTTP; Fri, 15 Jul 2011 10:28:24 -0700 (PDT) In-Reply-To: <379885BA631F4C7787C24E00A174B429@multiplay.co.uk> References: <379885BA631F4C7787C24E00A174B429@multiplay.co.uk> Date: Fri, 15 Jul 2011 10:28:24 -0700 Message-ID: From: Kevin Oberman To: Steven Hartland Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: igb enable_aim or flow_control causing tcp stalls? 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 Jul 2011 17:28:26 -0000 On Jul 15, 2011 9:59 AM, "Steven Hartland" wrote: > > Been trying to identify an strange network stalling issue while using > scp or rsync between two machines, initially at remote locations. > > The behaviour has proved quite difficult to track as it seems to require a > number or factors combined before the stalls occur. These seem to be: > 1. This particular target machine > 2. Some load, but not much on the machine, when idle we don't see stalls. > 3. Remote 9ms+ latency or high through put 50MB/s transmission speeds > > My current test case is copying a freebsd iso from a local machine to > the potentially problematic machine's /dev/null e.g. > scp FreeBSD-8.2-RELEASE-amd64-disc1.iso test1:/dev/null > > These machines are connected via a cisco 6509 -> supermicro blade > chassis. > > When the failure happens we see the following:- > scp FreeBSD-8.2-RELEASE-amd64-disc1.iso amsbld16:/dev/null > FreeBSD-8.2-RELEASE-amd64-disc1.iso 21% 147MB 2.1MB/s - stalled - > > When all is well we see:- > scp FreeBSD-8.2-RELEASE-amd64-disc1.iso amsbld16:/dev/null > FreeBSD-8.2-RELEASE-amd64-disc1.iso 100% 691MB 53.1MB/s 00:13 > > This setup:- > 1. Source machine 7.0-RELEASE-p2 using em0 > em0@pci0:6:0:0: class=0x020000 card=0x109615d9 chip=0x10968086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = 'PRO/1000 EB Network Connection' > class = network > subclass = ethernet > 2. Target (problem) machine 8.2-RELEASE using igb0 > igb0@pci0:5:0:0: class=0x020000 card=0x10e715d9 chip=0x10e78086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > > I've tried switching to igb1 with no change, which also changes > switches and hence ports on the Cisco, so I don't at this point > believe there is an issue there. > > Now I've just noticed that igb has at least two sysctl's which > seemed interesting, enable_aim & flow_control (which is missing > from the man page btw). On disabling both, the stalls seem to go away. > > Unfortunately re-enabling them didn't re-introduce the stalls, but > this could another quirk when they don't re-enable properly? > > So the questions are:- > 1. Could either of these settings cause tcp stalls? > 2. If the nic and switch differ in flow control, what is the likely > effect? > 3. Any other thoughts? Use "tcpdump -s0 -w file.pcap host remote-system" to see how it fails. You may want to capture on both ends. Then use wireshark (in ports) to analyze the data. There are other tools to provide other types of analysis, depending on the type of problem. R. Kevin Oberman, Network Engineer Retired kob6558@gmail.com From owner-freebsd-net@FreeBSD.ORG Sat Jul 16 06:44:14 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE83B106564A for ; Sat, 16 Jul 2011 06:44:14 +0000 (UTC) (envelope-from unccharlotte_hosted@uncc.edu) Received: from mx0b-00108101.pphosted.com (mx0b-00108101.pphosted.com [67.231.152.77]) by mx1.freebsd.org (Postfix) with ESMTP id 606028FC16 for ; Sat, 16 Jul 2011 06:44:13 +0000 (UTC) Received: from pps.filterd (m0001163 [127.0.0.1]) by mx0b-00108101.pphosted.com (8.14.4/8.14.4) with SMTP id p6G5wTL9011786 for ; Sat, 16 Jul 2011 02:12:51 -0400 Received: from uncc.edu (localhost [127.0.0.1]) by mx0b-00108101.pphosted.com with ESMTP id xjvuy98r9-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Sat, 16 Jul 2011 02:12:51 -0400 Received: from m0001163 (m0001163 [127.0.0.1]) by pps.default (8.14.1/8.14.1) with SMTP id p6G6CpU3026781 for ; Sat, 16 Jul 2011 02:12:51 -0400 Date: Sat, 16 Jul 2011 02:12:51 -0400 TO: freebsd-net@freebsd.org FROM: unccharlotte_hosted@uncc.edu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Message-ID: X-Proofpoint-Sentinel: stfsU2FsdGVkX194qH11lGeokTKaaMxG4ZYIO+lksbPWS9DC/nAOnfgSKfi8 0xZAqfuec/7S3wGwcGAQo+j1BWRqfLr3RgzHXPcPQHizFne8XqrQkH6FPFvAVIusTpFf59k7 Subject: Your E-mail Message Sent To A UNC Charlotte Address Has Been Blocked By The University's E-mail Security System 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 Jul 2011 06:44:14 -0000 Your message to ehernan3@uncc.edu, subject: [Virus email-worm:w32/mydoom.gen!a] Delivery reports about your e-mail, was blocked because it included a potentially malicious attachment. Please contact your intended recipient, without resending the attachment and let them know the message was blocked by the University's E-mail Security system. From owner-freebsd-net@FreeBSD.ORG Sat Jul 16 12:40:03 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B337106564A for ; Sat, 16 Jul 2011 12:40:03 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 617B98FC0A for ; Sat, 16 Jul 2011 12:40:02 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 72237153433; Sat, 16 Jul 2011 14:40:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcjIYoNBiMm1; Sat, 16 Jul 2011 14:39:58 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:c02b:ce62:71ff:9cbc] (unknown [IPv6:2001:4cb8:3:1:c02b:ce62:71ff:9cbc]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPSA id 73945153435; Sat, 16 Jul 2011 14:39:58 +0200 (CEST) Message-ID: <4E2186A5.4040707@digiware.nl> Date: Sat, 16 Jul 2011 14:40:05 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Steven Hartland References: <379885BA631F4C7787C24E00A174B429@multiplay.co.uk> In-Reply-To: <379885BA631F4C7787C24E00A174B429@multiplay.co.uk> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: igb enable_aim or flow_control causing tcp stalls? 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 Jul 2011 12:40:03 -0000 On 15-7-2011 18:47, Steven Hartland wrote: > Been trying to identify an strange network stalling issue while using > scp or rsync between two machines, initially at remote locations. > > The behaviour has proved quite difficult to track as it seems to require a > number or factors combined before the stalls occur. These seem to be: > 1. This particular target machine > 2. Some load, but not much on the machine, when idle we don't see stalls. > 3. Remote 9ms+ latency or high through put 50MB/s transmission speeds > > My current test case is copying a freebsd iso from a local machine to > the potentially problematic machine's /dev/null e.g. > scp FreeBSD-8.2-RELEASE-amd64-disc1.iso test1:/dev/null > > These machines are connected via a cisco 6509 -> supermicro blade > chassis. > > When the failure happens we see the following:- > scp FreeBSD-8.2-RELEASE-amd64-disc1.iso amsbld16:/dev/null > FreeBSD-8.2-RELEASE-amd64-disc1.iso 21% 147MB 2.1MB/s - stalled - > > When all is well we see:- > scp FreeBSD-8.2-RELEASE-amd64-disc1.iso amsbld16:/dev/null > FreeBSD-8.2-RELEASE-amd64-disc1.iso 100% 691MB 53.1MB/s 00:13 > > This setup:- > 1. Source machine 7.0-RELEASE-p2 using em0 > em0@pci0:6:0:0: class=0x020000 card=0x109615d9 chip=0x10968086 rev=0x01 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'PRO/1000 EB Network Connection' > class = network > subclass = ethernet > 2. Target (problem) machine 8.2-RELEASE using igb0 > igb0@pci0:5:0:0: class=0x020000 card=0x10e715d9 chip=0x10e78086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > > I've tried switching to igb1 with no change, which also changes > switches and hence ports on the Cisco, so I don't at this point > believe there is an issue there. > > Now I've just noticed that igb has at least two sysctl's which > seemed interesting, enable_aim & flow_control (which is missing > from the man page btw). On disabling both, the stalls seem to go away. > > Unfortunately re-enabling them didn't re-introduce the stalls, but > this could another quirk when they don't re-enable properly? > > So the questions are:- > 1. Could either of these settings cause tcp stalls? > 2. If the nic and switch differ in flow control, what is the likely > effect? > 3. Any other thoughts? I'm having more or less the same problems with a remote server with an em0 device running 7.2 (just upgraded to 7.4) and a 8.2 system..... Connection is limited on the way by 100Mbit-link, but other paths are all 1Gbit. Traffic starts at 20Mbit/sec but like after a minute we are down to 1Mbit/sec. Wait longer and it gets down to 250Kbit/s. And then starts to stall. But I suspect that in my case it is due to a mismatch of 100baseTX on the remote server, where the connection to the switch should be 1000baseTX. Reboots and all don't cure this, so I'll probably with have to go over and also kick the switch. Especially flowcontrol would be "upset" with such a mismatch. --WjW From owner-freebsd-net@FreeBSD.ORG Sat Jul 16 12:43:43 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7617B106566B for ; Sat, 16 Jul 2011 12:43:43 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0AAC28FC0A for ; Sat, 16 Jul 2011 12:43:42 +0000 (UTC) Received: by fxe6 with SMTP id 6so3130775fxe.17 for ; Sat, 16 Jul 2011 05:43:41 -0700 (PDT) Received: by 10.223.28.65 with SMTP id l1mr7061916fac.136.1310820221826; Sat, 16 Jul 2011 05:43:41 -0700 (PDT) Received: from [192.168.10.3] ([82.76.253.74]) by mx.google.com with ESMTPS id n27sm1492426faa.28.2011.07.16.05.43.39 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Jul 2011 05:43:40 -0700 (PDT) From: Vlad Galu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 16 Jul 2011 14:43:37 +0200 Message-Id: To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: FIB separation 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 Jul 2011 12:43:43 -0000 Hello, A couple of years ago, Stef Walter proposed a patch[1] that enforced the = scope of routing messages. The general consesus was that the best = approach would be the OpenBSD way - transporting the FIB number in the = message and letting the user applications filter out unwanted messages. Are there any plans to tackle this before 9.0? Thanks, Vlad [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/134931= From owner-freebsd-net@FreeBSD.ORG Sat Jul 16 15:28:29 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7CC0106566B for ; Sat, 16 Jul 2011 15:28:28 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 471E18FC14 for ; Sat, 16 Jul 2011 15:28:27 +0000 (UTC) Received: (qmail 72049 invoked from network); 16 Jul 2011 14:26:13 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 16 Jul 2011 14:26:13 -0000 Message-ID: <4E21AE1B.6070000@freebsd.org> Date: Sat, 16 Jul 2011 17:28:27 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Vladimir Budnev References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: (TCP/IP) Server side sends RST after 3-way handshake.Syn flood defense or queue overflow? 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 Jul 2011 15:28:29 -0000 On 13.07.2011 12:37, Vladimir Budnev wrote: > Hello. > > Iv faced some problem and seems don't realize the mechanincs why does it > occures. > First of all i'd like to notice that my freebsd knowledge and expirience is > limited, especially in such "strange" cases. > > In details(code example ill be at the end): > > System: > # uname -spr > FreeBSD 7.2-RELEASE amd64 > > We have simple TCP client and server. > > Server is very casual, it listens on some port in while->select->accept > loop. > > Client knocks on server port and sends some data and closes the port. > First it was designed for sending data 3-5/times per minute. But once during > test I'v noticed that if client sends data very fast (more precisely it > opens and closes socket to server very fast) there is > "54 - Connection reset by peer" error on call to "connect".(on client side > ofc) > > Some illustration from tcpdump: > (test on localhost.server side is port 10002.i'v cuted other fields for > simplicity) > <...> > 13:48:58.491229 IP 127.0.0.1.56677> 127.0.0.1.10002: S > 13:48:58.491255 IP 127.0.0.1.10002> 127.0.0.1.56677: S ack > 13:48:58.491266 IP 127.0.0.1.56677> 127.0.0.1.10002: . ack > 13:48:58.491300 IP 127.0.0.1.56677> 127.0.0.1.10002: P > 13:48:58.491346 IP 127.0.0.1.56677> 127.0.0.1.10002: F > 13:48:58.491365 IP 127.0.0.1.10002> 127.0.0.1.56677: . ack > > 13:48:58.491466 IP 127.0.0.1.55238> 127.0.0.1.10002: S // > 13:48:58.491490 IP 127.0.0.1.10002> 127.0.0.1.55238: S ack // handshake > 13:48:58.491503 IP 127.0.0.1.55238> 127.0.0.1.10002: . ack // > 13:48:58.491536 IP 127.0.0.1.55238> 127.0.0.1.10002: P<--data > 13:48:58.491580 IP 127.0.0.1.55238> 127.0.0.1.10002: F<-- client > closes session > 13:48:58.491599 IP 127.0.0.1.10002> 127.0.0.1.55238: . ack // OK > > 13:48:58.491701 IP 127.0.0.1.60212> 127.0.0.1.10002: S > 13:48:58.491726 IP 127.0.0.1.10002> 127.0.0.1.60212: S ack > 13:48:58.491738 IP 127.0.0.1.60212> 127.0.0.1.10002: . ack > 13:48:58.491745 IP 127.0.0.1.10002> 127.0.0.1.60212: R<-- this is > strange answer.Why? > > 13:48:58.491887 IP 127.0.0.1.60804> 127.0.0.1.10002: S > 13:48:58.491914 IP 127.0.0.1.10002> 127.0.0.1.60804: S ack > 13:48:58.491924 IP 127.0.0.1.60804> 127.0.0.1.10002: . ack > 13:48:58.491931 IP 127.0.0.1.10002> 127.0.0.1.60804: R > <...> > > Some connections were OK but then server application begin to send RST right > after handshake. > Tuning listen backlog parameter doesn't help much, BUT what really solves > the "problem" is increasing time interval between client > requests.egusleep(10000) solves the "problem" at all. > > Iv maned for some tuning like syncache and syncookies but nothing usefull, > or i missed something.But here they are: > > # sysctl -a | grep syncache > net.inet.tcp.syncache.rst_on_sock_fail: 1 > net.inet.tcp.syncache.rexmtlimit: 3 > net.inet.tcp.syncache.hashsize: 512 > net.inet.tcp.syncache.count: 0 > net.inet.tcp.syncache.cachelimit: 15360 > net.inet.tcp.syncache.bucketlimit: 30 > > > ipfw rules allows any from any, nothing special. > > QUESTION: > So the question is why such thing happening?Is this is some freebsd defense > from syn flood?(to be honest don't think so because seems there is no fixed > "ALLOWED syn/syn-ack/ack per seconds"). It more looks like some queue > overflow,but I don't know what queue and how it can be enlarged. > > If i can provide some more info to clear some aspects I will! When you enable "net.inet.tcp.log_debug=1" it will tell you at LOG_DEBUG level what went wrong and why it sent the RST. -- Andre From owner-freebsd-net@FreeBSD.ORG Sat Jul 16 15:43:11 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 789FF1065670 for ; Sat, 16 Jul 2011 15:43:11 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.vlsi.ee.noda.tus.ac.jp (sekine00.ee.noda.sut.ac.jp [133.31.107.40]) by mx1.freebsd.org (Postfix) with ESMTP id F10F68FC13 for ; Sat, 16 Jul 2011 15:43:10 +0000 (UTC) Received: from alph.allbsd.org (p3028-ipbf608funabasi.chiba.ocn.ne.jp [125.175.94.28]) (user=hrs mech=DIGEST-MD5 bits=128) by mail.vlsi.ee.noda.tus.ac.jp (8.14.4/8.14.4) with ESMTP id p6GFgqAB048453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Jul 2011 00:43:02 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p6GFgoX4063155; Sun, 17 Jul 2011 00:42:52 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sun, 17 Jul 2011 00:42:48 +0900 (JST) Message-Id: <20110717.004248.48765964696292481.hrs@allbsd.org> To: dudu@dudu.ro From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sun_Jul_17_00_42_48_2011_981)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.vlsi.ee.noda.tus.ac.jp [133.31.107.40]); Sun, 17 Jul 2011 00:43:02 +0900 (JST) X-Spam-Status: No, score=2.0 required=14.0 tests=BAYES_40, CONTENT_TYPE_PRESENT, RCVD_IN_RP_RNBL, SPF_SOFTFAIL, X_MAILER_PRESENT autolearn=no version=3.3.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.vlsi.ee.noda.tus.ac.jp Cc: freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: FIB separation 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 Jul 2011 15:43:11 -0000 ----Security_Multipart(Sun_Jul_17_00_42_48_2011_981)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Vlad Galu wrote in : du> Hello, du> du> A couple of years ago, Stef Walter proposed a patch[1] that enforced du> the scope of routing messages. The general consesus was that the best du> approach would be the OpenBSD way - transporting the FIB number in the du> message and letting the user applications filter out unwanted du> messages. du> du> Are there any plans to tackle this before 9.0? I am looking into this and investigating other possible extensions in rtsock messages such as addition of a fib member to rt_msghdr. I am not sure it can be done before 9.0, though... -- Hiroki ----Security_Multipart(Sun_Jul_17_00_42_48_2011_981)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk4hsXgACgkQTyzT2CeTzy1r7ACfbgol4iQfmS6VrGRpxJXyNJhh c3IAnRTg+4PdOqLwm9jkL6HZApfW/SiA =UC+i -----END PGP SIGNATURE----- ----Security_Multipart(Sun_Jul_17_00_42_48_2011_981)---- From owner-freebsd-net@FreeBSD.ORG Sat Jul 16 15:47:14 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05B0A106566B; Sat, 16 Jul 2011 15:47:14 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D1F128FC13; Sat, 16 Jul 2011 15:47:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6GFlDGO053797; Sat, 16 Jul 2011 15:47:13 GMT (envelope-from hrs@freefall.freebsd.org) Received: (from hrs@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6GFlDjl053793; Sat, 16 Jul 2011 15:47:13 GMT (envelope-from hrs) Date: Sat, 16 Jul 2011 15:47:13 GMT Message-Id: <201107161547.p6GFlDjl053793@freefall.freebsd.org> To: hrs@FreeBSD.org, freebsd-net@FreeBSD.org, hrs@FreeBSD.org From: hrs@FreeBSD.org Cc: Subject: Re: kern/134931: [route] Route messages sent to all socket listeners regardless of setfib(1) 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 Jul 2011 15:47:14 -0000 Synopsis: [route] Route messages sent to all socket listeners regardless of setfib(1) Responsible-Changed-From-To: freebsd-net->hrs Responsible-Changed-By: hrs Responsible-Changed-When: Sat Jul 16 15:46:50 UTC 2011 Responsible-Changed-Why: I'll take this. http://www.freebsd.org/cgi/query-pr.cgi?pr=134931 From owner-freebsd-net@FreeBSD.ORG Sat Jul 16 16:21:57 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D331106566C; Sat, 16 Jul 2011 16:21:57 +0000 (UTC) (envelope-from "melifaro@ipfw.ru"@mail.ipfw.ru) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8706B8FC15; Sat, 16 Jul 2011 16:21:56 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from <"melifaro@ipfw.ru"@mail.ipfw.ru>) id 1Qi7co-0001Lq-V6; Sat, 16 Jul 2011 20:21:55 +0400 Message-ID: <4E21BA0B.6080800@ipfw.ru> Date: Sat, 16 Jul 2011 20:19:23 +0400 From: "Alexander V. Chernikov" User-Agent: Thunderbird 2.0.0.24 (X11/20100515) MIME-Version: 1.0 To: Hiroki Sato References: <20110717.004248.48765964696292481.hrs@allbsd.org> In-Reply-To: <20110717.004248.48765964696292481.hrs@allbsd.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------000402000609000100040606" Sender: "melifaro@ipfw.ru"@mail.ipfw.ru Cc: freebsd-hackers@FreeBSD.org, dudu@dudu.ro, "Bjoern A. Zeeb" , freebsd-net@FreeBSD.org Subject: Re: FIB separation 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 Jul 2011 16:21:57 -0000 This is a multi-part message in MIME format. --------------000402000609000100040606 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hiroki Sato wrote: > Vlad Galu wrote > in : > > du> Hello, > du> > du> A couple of years ago, Stef Walter proposed a patch[1] that enforced > du> the scope of routing messages. The general consesus was that the best > du> approach would be the OpenBSD way - transporting the FIB number in the > du> message and letting the user applications filter out unwanted > du> messages. > du> > du> Are there any plans to tackle this before 9.0? > > I am looking into this and investigating other possible extensions in > rtsock messages such as addition of a fib member to rt_msghdr. I am > not sure it can be done before 9.0, though... Actually there were an off-list discussion with bz@ and julian@ about interface fibs and rtsock changes several weeks ago. Initial messages: http://lists.freebsd.org/pipermail/freebsd-net/2011-June/029040.html I've got 3 different patches: 1) straight forwarded kern/134931 fix (no fib in rtsock, no breaking ABI, send to bz@) 2) adding fib in rtsock with rtsock versioning and other ABI keeping tricks 3) adding special RTA which can contain TLV pairs, with single defined TLV with routing socket As a result of discussion, first patch was sent to bz@. Since patches from kern/134931 are outdated attaching it here. It is very much like original patch from kern/134931. The only difference is using PACKET_TAG_RTSOCKFAM mbuf_tag more heavily. This is required for keeping raw_input() with same number of parameters. Actually it looks rather hackish now. > > -- Hiroki -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4hugsACgkQwcJ4iSZ1q2nd1gCcDAgOIEjNbunK9QeADDEvyMa8 WtYAn1rlwUMzeSh1nX8o7Pw5TpZsfCJx =TsVz -----END PGP SIGNATURE----- --------------000402000609000100040606 Content-Type: text/plain; name="rtmsg_20110704-CURRENT.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rtmsg_20110704-CURRENT.diff" Index: netinet/in.c =================================================================== --- netinet/in.c (revision 223741) +++ netinet/in.c (working copy) @@ -1009,7 +1009,7 @@ static void in_addralias_rtmsg(int cmd, struct in_ (struct sockaddr *)&target->ia_addr; rt_newaddrmsg(cmd, (struct ifaddr *)target, - 0, &msg_rt); + 0, &msg_rt, RT_ALLFIBS); RTFREE(pfx_ro.ro_rt); } return; Index: net/route.c =================================================================== --- net/route.c (revision 223741) +++ net/route.c (working copy) @@ -384,7 +384,7 @@ miss: */ bzero(&info, sizeof(info)); info.rti_info[RTAX_DST] = dst; - rt_missmsg(msgtype, &info, 0, err); + rt_missmsg(msgtype, &info, 0, err, fibnum); } done: if (newrt) @@ -609,7 +609,7 @@ out: info.rti_info[RTAX_GATEWAY] = gateway; info.rti_info[RTAX_NETMASK] = netmask; info.rti_info[RTAX_AUTHOR] = src; - rt_missmsg(RTM_REDIRECT, &info, flags, error); + rt_missmsg(RTM_REDIRECT, &info, flags, error, fibnum); if (ifa != NULL) ifa_free(ifa); } @@ -1522,7 +1522,7 @@ rtinit1(struct ifaddr *ifa, int cmd, int flags, in } RT_ADDREF(rt); RT_UNLOCK(rt); - rt_newaddrmsg(cmd, ifa, error, rt); + rt_newaddrmsg(cmd, ifa, error, rt, fibnum); RT_LOCK(rt); RT_REMREF(rt); if (cmd == RTM_DELETE) { Index: net/route.h =================================================================== --- net/route.h (revision 223741) +++ net/route.h (working copy) @@ -303,6 +303,11 @@ struct rt_addrinfo { struct ifnet *rti_ifp; }; +struct rt_dispatch_ctx { + unsigned short family; /* Socket family */ + int fibnum; /* FIB for message or -1 for all */ +}; + /* * This macro returns the size of a struct sockaddr when passed * through a routing socket. Basically we round up sa_len to @@ -317,6 +322,8 @@ struct rt_addrinfo { #ifdef _KERNEL +#define RT_ALLFIBS -1 + #define RT_LINK_IS_UP(ifp) (!((ifp)->if_capabilities & IFCAP_LINKSTATE) \ || (ifp)->if_link_state == LINK_STATE_UP) @@ -364,8 +371,8 @@ struct ifmultiaddr; void rt_ieee80211msg(struct ifnet *, int, void *, size_t); void rt_ifannouncemsg(struct ifnet *, int); void rt_ifmsg(struct ifnet *); -void rt_missmsg(int, struct rt_addrinfo *, int, int); -void rt_newaddrmsg(int, struct ifaddr *, int, struct rtentry *); +void rt_missmsg(int, struct rt_addrinfo *, int, int, int); +void rt_newaddrmsg(int, struct ifaddr *, int, struct rtentry *, int); void rt_newmaddrmsg(int, struct ifmultiaddr *); int rt_setgate(struct rtentry *, struct sockaddr *, struct sockaddr *); void rt_maskedcopy(struct sockaddr *, struct sockaddr *, struct sockaddr *); Index: net/rtsock.c =================================================================== --- net/rtsock.c (revision 223741) +++ net/rtsock.c (working copy) @@ -159,7 +159,7 @@ static void rt_setmetrics(u_long which, const stru struct rt_metrics_lite *out); static void rt_getmetrics(const struct rt_metrics_lite *in, struct rt_metrics *out); -static void rt_dispatch(struct mbuf *, const struct sockaddr *); +static void rt_dispatch(struct mbuf *, const struct sockaddr *, int); static struct netisr_handler rtsock_nh = { .nh_name = "rtsock", @@ -200,17 +200,16 @@ static void rts_input(struct mbuf *m) { struct sockproto route_proto; - unsigned short *family; + struct rt_dispatch_ctx *ctx; struct m_tag *tag; route_proto.sp_family = PF_ROUTE; - tag = m_tag_find(m, PACKET_TAG_RTSOCKFAM, NULL); + route_proto.sp_protocol = 0; + tag = m_tag_find(m, PACKET_TAG_RTSOCK, NULL); if (tag != NULL) { - family = (unsigned short *)(tag + 1); - route_proto.sp_protocol = *family; - m_tag_delete(m, tag); - } else - route_proto.sp_protocol = 0; + ctx = (struct rt_dispatch_ctx*)(tag + 1); + route_proto.sp_protocol = ctx->family; + } raw_input(m, &route_proto, &route_src); } @@ -892,10 +891,10 @@ flush: */ unsigned short family = rp->rcb_proto.sp_family; rp->rcb_proto.sp_family = 0; - rt_dispatch(m, info.rti_info[RTAX_DST]); + rt_dispatch(m, info.rti_info[RTAX_DST], so->so_fibnum); rp->rcb_proto.sp_family = family; } else - rt_dispatch(m, info.rti_info[RTAX_DST]); + rt_dispatch(m, info.rti_info[RTAX_DST], so->so_fibnum); } /* info.rti_info[RTAX_DST] (used above) can point inside of rtm */ if (rtm) @@ -1127,7 +1126,7 @@ again: * destination. */ void -rt_missmsg(int type, struct rt_addrinfo *rtinfo, int flags, int error) +rt_missmsg(int type, struct rt_addrinfo *rtinfo, int flags, int error, int fibnum) { struct rt_msghdr *rtm; struct mbuf *m; @@ -1142,7 +1141,7 @@ void rtm->rtm_flags = RTF_DONE | flags; rtm->rtm_errno = error; rtm->rtm_addrs = rtinfo->rti_addrs; - rt_dispatch(m, sa); + rt_dispatch(m, sa, fibnum); } /* @@ -1167,7 +1166,7 @@ rt_ifmsg(struct ifnet *ifp) ifm->ifm_flags = ifp->if_flags | ifp->if_drv_flags; ifm->ifm_data = ifp->if_data; ifm->ifm_addrs = 0; - rt_dispatch(m, NULL); + rt_dispatch(m, NULL, RT_ALLFIBS); } /* @@ -1179,7 +1178,7 @@ rt_ifmsg(struct ifnet *ifp) * copies of it. */ void -rt_newaddrmsg(int cmd, struct ifaddr *ifa, int error, struct rtentry *rt) +rt_newaddrmsg(int cmd, struct ifaddr *ifa, int error, struct rtentry *rt, int fibnum) { struct rt_addrinfo info; struct sockaddr *sa = NULL; @@ -1237,7 +1236,7 @@ void rtm->rtm_errno = error; rtm->rtm_addrs = info.rti_addrs; } - rt_dispatch(m, sa); + rt_dispatch(m, sa, fibnum); } } @@ -1273,7 +1272,7 @@ rt_newmaddrmsg(int cmd, struct ifmultiaddr *ifma) __func__)); ifmam->ifmam_index = ifp->if_index; ifmam->ifmam_addrs = info.rti_addrs; - rt_dispatch(m, ifma->ifma_addr); + rt_dispatch(m, ifma->ifma_addr, RT_ALLFIBS); } static struct mbuf * @@ -1333,7 +1332,7 @@ rt_ieee80211msg(struct ifnet *ifp, int what, void if (m->m_flags & M_PKTHDR) m->m_pkthdr.len += data_len; mtod(m, struct if_announcemsghdr *)->ifan_msglen += data_len; - rt_dispatch(m, NULL); + rt_dispatch(m, NULL, RT_ALLFIBS); } } @@ -1349,27 +1348,30 @@ rt_ifannouncemsg(struct ifnet *ifp, int what) m = rt_makeifannouncemsg(ifp, RTM_IFANNOUNCE, what, &info); if (m != NULL) - rt_dispatch(m, NULL); + rt_dispatch(m, NULL, RT_ALLFIBS); } static void -rt_dispatch(struct mbuf *m, const struct sockaddr *sa) +rt_dispatch(struct mbuf *m, const struct sockaddr *sa, int fibnum) { + struct rt_dispatch_ctx *ctx; struct m_tag *tag; /* * Preserve the family from the sockaddr, if any, in an m_tag for * use when injecting the mbuf into the routing socket buffer from - * the netisr. + * the netisr. Additionally save the fibnum if needed. */ - if (sa != NULL) { - tag = m_tag_get(PACKET_TAG_RTSOCKFAM, sizeof(unsigned short), - M_NOWAIT); + if (sa != NULL || fibnum >= 0) { + tag = m_tag_get(PACKET_TAG_RTSOCK, + sizeof(struct rt_dispatch_ctx*), M_NOWAIT); if (tag == NULL) { m_freem(m); return; } - *(unsigned short *)(tag + 1) = sa->sa_family; + ctx = (struct rt_dispatch_ctx*)(tag + 1); + ctx->family = sa->sa_family; + ctx->fibnum = fibnum; m_tag_prepend(m, tag); } #ifdef VIMAGE Index: net/raw_usrreq.c =================================================================== --- net/raw_usrreq.c (revision 223741) +++ net/raw_usrreq.c (working copy) @@ -48,6 +48,7 @@ #include #include #include +#include MTX_SYSINIT(rawcb_mtx, &rawcb_mtx, "rawcb", MTX_DEF); @@ -74,7 +75,18 @@ raw_input(struct mbuf *m0, struct sockproto *proto struct rawcb *rp; struct mbuf *m = m0; struct socket *last; + struct rt_dispatch_ctx *ctx; + struct m_tag *tag = NULL; + int fibnum = RT_ALLFIBS; + if (proto->sp_family == PF_ROUTE) { + tag = m_tag_find(m, PACKET_TAG_RTSOCK, NULL); + if (tag != NULL) { + ctx = (struct rt_dispatch_ctx*)(tag + 1); + fibnum = ctx->fibnum; + } + } + last = 0; mtx_lock(&rawcb_mtx); LIST_FOREACH(rp, &V_rawcb_list, list) { @@ -83,6 +95,10 @@ raw_input(struct mbuf *m0, struct sockproto *proto if (rp->rcb_proto.sp_protocol && rp->rcb_proto.sp_protocol != proto->sp_protocol) continue; + if ((proto->sp_family == PF_ROUTE) && (fibnum >= 0) && + (rp->rcb_socket != NULL) && + (fibnum != rp->rcb_socket->so_fibnum)) + continue; if (last) { struct mbuf *n; n = m_copy(m, 0, (int)M_COPYALL); Index: netinet6/in6.c =================================================================== --- netinet6/in6.c (revision 223741) +++ netinet6/in6.c (working copy) @@ -1280,7 +1280,7 @@ in6_purgeaddr(struct ifaddr *ifa) rt_mask(&rt0) = (struct sockaddr *)&mask; rt_key(&rt0) = (struct sockaddr *)&addr; rt0.rt_flags = RTF_HOST | RTF_STATIC; - rt_newaddrmsg(RTM_DELETE, ifa, 0, &rt0); + rt_newaddrmsg(RTM_DELETE, ifa, 0, &rt0, RT_ALLFIBS); /* * leave from multicast groups we have joined for the interface @@ -1858,7 +1858,7 @@ in6_ifinit(struct ifnet *ifp, struct in6_ifaddr *i rt_mask(&rt) = (struct sockaddr *)&mask; rt_key(&rt) = (struct sockaddr *)&addr; rt.rt_flags = RTF_UP | RTF_HOST | RTF_STATIC; - rt_newaddrmsg(RTM_ADD, &ia->ia_ifa, 0, &rt); + rt_newaddrmsg(RTM_ADD, &ia->ia_ifa, 0, &rt, RT_ALLFIBS); } return (error); Index: netinet6/nd6_rtr.c =================================================================== --- netinet6/nd6_rtr.c (revision 223741) +++ netinet6/nd6_rtr.c (working copy) @@ -458,7 +458,7 @@ nd6_rtmsg(int cmd, struct rtentry *rt) } else ifa = NULL; - rt_missmsg(cmd, &info, rt->rt_flags, 0); + rt_missmsg(cmd, &info, rt->rt_flags, 0, RT_ALLFIBS); if (ifa != NULL) ifa_free(ifa); } Index: sys/mbuf.h =================================================================== --- sys/mbuf.h (revision 223741) +++ sys/mbuf.h (working copy) @@ -945,7 +945,7 @@ struct mbuf *m_unshare(struct mbuf *, int how); #define PACKET_TAG_IPFORWARD 18 /* ipforward info */ #define PACKET_TAG_MACLABEL (19 | MTAG_PERSISTENT) /* MAC label */ #define PACKET_TAG_PF 21 /* PF + ALTQ information */ -#define PACKET_TAG_RTSOCKFAM 25 /* rtsock sa family */ +#define PACKET_TAG_RTSOCK 25 /* rtsock info */ #define PACKET_TAG_IPOPTIONS 27 /* Saved IP options */ #define PACKET_TAG_CARP 28 /* CARP info */ #define PACKET_TAG_IPSEC_NAT_T_PORTS 29 /* two uint16_t */ --------------000402000609000100040606-- From owner-freebsd-net@FreeBSD.ORG Sat Jul 16 16:22:16 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0248E106564A; Sat, 16 Jul 2011 16:22:16 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id 6B6E58FC12; Sat, 16 Jul 2011 16:22:14 +0000 (UTC) Received: by fxe6 with SMTP id 6so3281298fxe.17 for ; Sat, 16 Jul 2011 09:22:14 -0700 (PDT) Received: by 10.223.53.77 with SMTP id l13mr7160459fag.84.1310833334029; Sat, 16 Jul 2011 09:22:14 -0700 (PDT) Received: from [192.168.10.3] ([82.76.253.74]) by mx.google.com with ESMTPS id r12sm1607684fam.0.2011.07.16.09.22.12 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Jul 2011 09:22:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Vlad Galu In-Reply-To: <20110717.004248.48765964696292481.hrs@allbsd.org> Date: Sat, 16 Jul 2011 18:22:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <08E81571-34DA-41E2-B06E-3BFC9C046895@dudu.ro> References: <20110717.004248.48765964696292481.hrs@allbsd.org> To: Hiroki Sato X-Mailer: Apple Mail (2.1084) Cc: freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: FIB separation 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 Jul 2011 16:22:16 -0000 On Jul 16, 2011, at 5:42 PM, Hiroki Sato wrote: > Vlad Galu wrote > in : >=20 > du> Hello, > du> > du> A couple of years ago, Stef Walter proposed a patch[1] that = enforced > du> the scope of routing messages. The general consesus was that the = best > du> approach would be the OpenBSD way - transporting the FIB number in = the > du> message and letting the user applications filter out unwanted > du> messages. > du> > du> Are there any plans to tackle this before 9.0? >=20 > I am looking into this and investigating other possible extensions in > rtsock messages such as addition of a fib member to rt_msghdr. I am > not sure it can be done before 9.0, though... >=20 > -- Hiroki Thanks! Even if this gets postponed for 10.0, living with a backport of = the official implementation would be easier than maintaining a homegrown solution. VG