From owner-freebsd-net@FreeBSD.ORG Sun Jul 17 12:14:36 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E3D9106564A for ; Sun, 17 Jul 2011 12:14:36 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id EE45E8FC12 for ; Sun, 17 Jul 2011 12:14:35 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QiQ0S-0004Yb-KN for freebsd-net@freebsd.org; Sun, 17 Jul 2011 13:59:32 +0200 Received: from 208.88.188.90.adsl.tomsknet.ru ([90.188.88.208]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Jul 2011 13:59:32 +0200 Received: from vadim_nuclight by 208.88.188.90.adsl.tomsknet.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Jul 2011 13:59:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Vadim Goncharov Date: Sun, 17 Jul 2011 11:59:17 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 159 Message-ID: References: <20110714154457.GI70776@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 208.88.188.90.adsl.tomsknet.ru X-Comment-To: Gleb Smirnoff User-Agent: slrn/0.9.9p1 (FreeBSD) Subject: Re: m_pkthdr.rcvif dangling pointer problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 12:14:36 -0000 Hi Gleb Smirnoff! On Thu, 14 Jul 2011 19:44:57 +0400; Gleb Smirnoff wrote about 'm_pkthdr.rcvif dangling pointer 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. Conceptually, this is the most correct solution, though not so fast. Ways to improve are to be found from this starting point. However, are that +2 atomic ops per packet really so expensive? How many of atomic ops are already on that path? Any measures? > 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. Indeed, for long-term solution this is not right approach. > 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) > { [...] > ifp = ifnet_byindex_locked(m->m_pkthdr.rcvif_idx); [...] > 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. This solution has several other drawbacks: 1) It slows down rcvif dereference on _every_ ifnet lookup during packet lifetime. That's not just +2 ops but there could be many of them. 2) It requires converting *all* consumers of rcvif pointer in the kernel. Solution requiring to change everything are usually smell bad, could introduce bugs, and at least one case already found - net80211. 3) It comlicates not only the code, but requires additional 4 bytes of pkthdr on non-64bit architectures (i386, MIPS, ARM?) > Any alternative ideas on solving the problem are welcome! Yes, I have one, a somewhat hybrid of solutions 1 and 3. First, we leave all mbuf consumers and rcvif pointer as is. We then add two new fields: struct pkthdr { + uint16_t gencount; /* iftable version */ + uint16_t fib; /* may be reserve some bits? */ We need only 16 bits, and fib must be moved from mbuf flags anyway. I'm not sure this should be all 16 bits - we may want to use e.g. 12 bits for FIB number and 4 bits for M_HASHTYPEBITS which was placed to flags with the same hack as M_FIB ?.. This should be thought, too, but let's continue with our problem. So, we have a global variable: int iftable_gencount; /* generation counter */ this should be updated (atomically) on every operation with interfaces table, that is, on every interface departure and arrival. And when an interface is created, it gets: struct ifnet { + int gencount; /* iftable version */ at the moment of creation. This valuse then doesn't change. After then, when a new mbuf w/pkthdr is allocated, it's mb_ctor_mbuf() does: pkthdr.gencount = iftable_gencount & 0xffff; And this value also doesn't change during entire mbuf lifetime. At the same time, along with setting pkthdr.gencount, an entry in the special array, let's call it a[], is updated: index: gencount=1 gencount=2 gencount=3 +-----------+-----------+-----------+---....... |atomic_int |atomic_int |atomic_int | +-----------+-----------+-----------+---....... Those entries a[gencount] show the total number of mbufs with the same pkthdr.gencount in the system (it is decreased by mb_dtor_mbuf() on mbuf freeing). You can say, that's atomic too as in solution 1, but wait a little. Now, let's say em0 was created with gencount=1, ng0 was with gencount=2, and now ng0 is being destroyed. Now, global iftable_gencount is now 3, and all new mbufs in the system will get pkthdr.gencount=3, so numbers in previous generations now could only decrease, not grow. The ng0 if if_ref()'ed once by generation counting code and is not released until the SUM of all previous generations is zero (that is, for both gencount=1 and gencount=2). We observe that this counts could only decrease, so now this scheme could be converted to be lockless! We copy array a[] into every CPU's private memory, and all this copies are now accessed lockless, and now what matters for every generation is sum of all per-CPU values (this costs, however, 256K of memory on 32-bit archs). Now, a callout(9)-garbage collector procedure is invoked every N secs and scans arrays of all CPU without atomic(9) and sums that. If a value is stale in some cache - nothing harmless, numbers could only decrease, the if_rele() will be just deferred to next pass. Of course, this requires memory, and a TCP-like arithmetics for wrapping array in 2^16 space. So the only other problem which could be is when some mbuf exists too long to survive 32767 interfaces creates and destroys, which is very unlikely. Unfortunatelly, I don't know how to write per-CPU code, so I can't give you a PoC patch, but I hope I've explained idea detailed enough. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-net@FreeBSD.ORG Sun Jul 17 14:15: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 20A8A1065670 for ; Sun, 17 Jul 2011 14:15:07 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ey0-f176.google.com (mail-ey0-f176.google.com [209.85.215.176]) by mx1.freebsd.org (Postfix) with ESMTP id A00E98FC08 for ; Sun, 17 Jul 2011 14:15:06 +0000 (UTC) Received: by eya28 with SMTP id 28so1990826eya.21 for ; Sun, 17 Jul 2011 07:15:05 -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=4pqtnzr7WIomp1GtyWw+zhoqEwvn9mhhE8RDgVssHpM=; b=aVDzM/V2sxLYetDWy+YZxX5Td+Lq/NtuIFtUEiKONIyTg+jSH9mvNRXO73Q62o2M0v DMBIHEb+vNID29F37rgkqtQklkyXqRbIqIaK7x8SdUrsx8FRUng6lzVYehKekolz1aM9 liVGuLI2FQoIVXh1y8mRtp1homq47hvMhdwOE= MIME-Version: 1.0 Received: by 10.213.21.2 with SMTP id h2mr1916512ebb.90.1310912105423; Sun, 17 Jul 2011 07:15:05 -0700 (PDT) Received: by 10.213.15.70 with HTTP; Sun, 17 Jul 2011 07:15:05 -0700 (PDT) In-Reply-To: References: <20110714154457.GI70776@FreeBSD.org> Date: Sun, 17 Jul 2011 10:15:05 -0400 Message-ID: From: Ryan Stone To: vadim_nuclight@mail.ru Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-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: Sun, 17 Jul 2011 14:15:07 -0000 On Sun, Jul 17, 2011 at 7:59 AM, Vadim Goncharov wrote: > Ways to improve are to be found from this starting point. However, > are that +2 atomic ops per packet really so expensive? How many of > atomic ops are already on that path? Any measures? On high-performance multiqueue NICs, those two atomic ops are pretty well guaranteed to be contended every time. It's a scalability nightmare. From owner-freebsd-net@FreeBSD.ORG Mon Jul 18 06:48:04 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9872E106564A for ; Mon, 18 Jul 2011 06:48:04 +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 4E9EE8FC0A for ; Mon, 18 Jul 2011 06:48:03 +0000 (UTC) Received: by vws18 with SMTP id 18so2724508vws.13 for ; Sun, 17 Jul 2011 23:48:03 -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=m2RsVkSKPzJFxjQA/PzngkgH5rVa9HQP12GaO7d5MtE=; b=Ui3wo/Sje9QbxxfLtUrjo/bxwtcZW2IoluT1FG8//PIz9kd1qrzEzWbYMBPg3/DlKf +zPcFeMVC4lHUl2ubQFcEcMjJ1L3zq3u1bM15QItlpjgYJEMgu8arn7+MMBaf7gmFnv2 ByG2qHHOZXOuVuW0rnkkSJiH2RTLoNmCJSsGM= MIME-Version: 1.0 Received: by 10.220.108.77 with SMTP id e13mr683234vcp.79.1310971683243; Sun, 17 Jul 2011 23:48:03 -0700 (PDT) Received: by 10.220.178.129 with HTTP; Sun, 17 Jul 2011 23:48:03 -0700 (PDT) In-Reply-To: <4E21AE1B.6070000@freebsd.org> References: <4E21AE1B.6070000@freebsd.org> Date: Mon, 18 Jul 2011 10:48:03 +0400 Message-ID: From: Vladimir Budnev To: Andre Oppermann 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: Mon, 18 Jul 2011 06:48:04 -0000 > 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. > Thank you Andre. Now its clear what causes the problem, here is what i got in logs: Jul 18 10:33:55 kernel: TCP: [127.0.0.1]:52971 to [127.0.0.1]:10002 tcpflags 0x10; tcp_input: Listen socket: Socket allocation failed due to limits or memory shortage, sending RST I'v decided not to tune system parametrs cause it looks like a "crutch". I'll rewrite data sending mechanism to "one connection and stream transmission fro all chunks" instead of "one connection for each data chunk". That way there will be no more huge connections amount per second to the server side. From owner-freebsd-net@FreeBSD.ORG Mon Jul 18 11:07:08 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FA721065721 for ; Mon, 18 Jul 2011 11:07:08 +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 2D3FF8FC12 for ; Mon, 18 Jul 2011 11:07:08 +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 p6IB78Zc026850 for ; Mon, 18 Jul 2011 11:07:08 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6IB77Xx026848 for freebsd-net@FreeBSD.org; Mon, 18 Jul 2011 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 18 Jul 2011 11:07:07 GMT Message-Id: <201107181107.p6IB77Xx026848@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, 18 Jul 2011 11:07:08 -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/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/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/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 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 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o 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/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 379 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jul 18 11:31: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 869B5106566B for ; Mon, 18 Jul 2011 11:31:33 +0000 (UTC) (envelope-from prvs=11805abe50=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 9DA148FC1F for ; Mon, 18 Jul 2011 11:31:31 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Mon, 18 Jul 2011 12:19:57 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 18 Jul 2011 12:19:54 +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 md50014205614.msg for ; Mon, 18 Jul 2011 12:19:53 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=11805abe50=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: From: "Steven Hartland" To: "Kevin Oberman" References: <379885BA631F4C7787C24E00A174B429@multiplay.co.uk> Date: Mon, 18 Jul 2011 12:20:14 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_037F_01CC4545.0BE2BA90" 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 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: Mon, 18 Jul 2011 11:31:33 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_037F_01CC4545.0BE2BA90 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Kevin Oberman" > > 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. I've managed to get a capture from both ends but its doesn't really make too much sense to me. You can clearly see the stall which starts at the 2.1 second mark, and recovers at the 65 second mark but what's causing it is a mystery. I've attached what I believe is the relevant a snippet from each trace. At this point I believe I've eliminated aim and flow_control as these where both off when this test was preformed Any advice would be appreciated. The layout for this test was:- Source (7.0-RELEASE-p2 on em0) -> Cisco 6509 -> supermicro blade -> Target (8.2-RELEASE on igb0) I'm going to try and eliminate the Cisco next by going from two blades on the local supermicro blade switch. 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. ------=_NextPart_000_037F_01CC4545.0BE2BA90 Content-Type: text/plain; format=flowed; name="source-pcap-snip.txt"; reply-type=original Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="source-pcap-snip.txt" 00:00:02.133714 IP (tos 0x8, ttl 63, id 44772, offset 0, flags [DF], = proto TCP (6), length 52)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115884592, win 7113, options [nop,nop,TS val = 4130741282 ecr 442166723], length 0=0A= 00:00:02.133812 IP (tos 0x8, ttl 63, id 44773, offset 0, flags [DF], = proto TCP (6), length 52)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115887488, win 7054, options [nop,nop,TS val = 4130741282 ecr 442166723], length 0=0A= 00:00:02.133815 IP (tos 0x8, ttl 63, id 44774, offset 0, flags [DF], = proto TCP (6), length 52)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115890384, win 6873, options [nop,nop,TS val = 4130741282 ecr 442166723], length 0=0A= 00:00:02.133927 IP bad-len 0=0A= 00:00:02.133938 IP (tos 0x8, ttl 63, id 44775, offset 0, flags [DF], = proto TCP (6), length 52)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115893280, win 6692, options [nop,nop,TS val = 4130741282 ecr 442166723], length 0=0A= 00:00:02.133944 IP (tos 0x8, ttl 63, id 44776, offset 0, flags [DF], = proto TCP (6), length 52)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115896176, win 6511, options [nop,nop,TS val = 4130741282 ecr 442166723], length 0=0A= 00:00:02.133950 IP (tos 0x8, ttl 63, id 44777, offset 0, flags [DF], = proto TCP (6), length 52)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115897624, win 7235, options [nop,nop,TS val = 4130741282 ecr 442166723], length 0=0A= 00:00:02.133953 IP (tos 0x8, ttl 63, id 44778, offset 0, flags [DF], = proto TCP (6), length 64)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7144, options [nop,nop,TS val = 4130741282 ecr 442166723,nop,nop,sack 1 {115900520:115901024}], length 0=0A= 00:00:02.133957 IP (tos 0x8, ttl 63, id 44779, offset 0, flags [DF], = proto TCP (6), length 64)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741282 ecr 442166723,nop,nop,sack 1 {115900520:115902472}], length 0=0A= 00:00:02.133959 IP (tos 0x8, ttl 63, id 44780, offset 0, flags [DF], = proto TCP (6), length 64)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741282 ecr 442166723,nop,nop,sack 1 {115900520:115903920}], length 0=0A= 00:00:02.134061 IP (tos 0x8, ttl 63, id 44781, offset 0, flags [DF], = proto TCP (6), length 64)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741282 ecr 442166723,nop,nop,sack 1 {115900520:115905368}], length 0=0A= 00:00:02.134065 IP (tos 0x8, ttl 63, id 44782, offset 0, flags [DF], = proto TCP (6), length 64)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741282 ecr 442166723,nop,nop,sack 1 {115900520:115906816}], length 0=0A= 00:00:02.134072 IP (tos 0x8, ttl 64, id 47143, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115899072:115900520, ack 50481, win 130, options [nop,nop,TS = val 442166724 ecr 4130741282], length 1448=0A= 00:00:02.134075 IP (tos 0x8, ttl 63, id 44783, offset 0, flags [DF], = proto TCP (6), length 64)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741282 ecr 442166723,nop,nop,sack 1 {115900520:115908264}], length 0=0A= 00:00:02.134078 IP (tos 0x8, ttl 63, id 44784, offset 0, flags [DF], = proto TCP (6), length 64)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741282 ecr 442166723,nop,nop,sack 1 {115900520:115909712}], length 0=0A= 00:00:02.134160 IP bad-len 0=0A= 00:00:02.134187 IP (tos 0x8, ttl 63, id 44785, offset 0, flags [DF], = proto TCP (6), length 64)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741282 ecr 442166723,nop,nop,sack 1 {115900520:115911160}], length 0=0A= 00:00:02.134197 IP (tos 0x8, ttl 64, id 47145, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115936784:115938232, ack 50481, win 130, options [nop,nop,TS = val 442166724 ecr 4130741282], length 1448=0A= 00:00:02.134201 IP (tos 0x8, ttl 63, id 44786, offset 0, flags [DF], = proto TCP (6), length 64)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741282 ecr 442166723,nop,nop,sack 1 {115900520:115912608}], length 0=0A= 00:00:02.134205 IP (tos 0x8, ttl 64, id 47146, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115938232:115939680, ack 50481, win 130, options [nop,nop,TS = val 442166724 ecr 4130741282], length 1448=0A= 00:00:02.134208 IP (tos 0x8, ttl 63, id 44787, offset 0, flags [DF], = proto TCP (6), length 64)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741282 ecr 442166723,nop,nop,sack 1 {115900520:115914056}], length 0=0A= 00:00:02.134213 IP (tos 0x8, ttl 64, id 47147, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115939680:115941128, ack 50481, win 130, options [nop,nop,TS = val 442166724 ecr 4130741282], length 1448=0A= 00:00:02.134215 IP (tos 0x8, ttl 63, id 44788, offset 0, flags [DF], = proto TCP (6), length 64)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741282 ecr 442166723,nop,nop,sack 1 {115900520:115915504}], length 0=0A= 00:00:02.134220 IP (tos 0x8, ttl 64, id 47148, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115941128:115942576, ack 50481, win 130, options [nop,nop,TS = val 442166724 ecr 4130741282], length 1448=0A= 00:00:02.134223 IP (tos 0x8, ttl 63, id 44789, offset 0, flags [DF], = proto TCP (6), length 64)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741282 ecr 442166723,nop,nop,sack 1 {115900520:115916952}], length 0=0A= 00:00:02.134227 IP (tos 0x8, ttl 64, id 47149, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115942576:115944024, ack 50481, win 130, options [nop,nop,TS = val 442166724 ecr 4130741282], length 1448=0A= 00:00:02.134230 IP (tos 0x8, ttl 63, id 44790, offset 0, flags [DF], = proto TCP (6), length 64)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741282 ecr 442166723,nop,nop,sack 1 {115900520:115917456}], length 0=0A= 00:00:02.134235 IP (tos 0x8, ttl 64, id 47150, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115944024:115945472, ack 50481, win 130, options [nop,nop,TS = val 442166724 ecr 4130741282], length 1448=0A= 00:00:02.134237 IP (tos 0x8, ttl 63, id 44791, offset 0, flags [DF], = proto TCP (6), length 64)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741282 ecr 442166723,nop,nop,sack 1 {115900520:115918904}], length 0=0A= 00:00:02.134242 IP (tos 0x8, ttl 64, id 47151, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115945472:115946920, ack 50481, win 130, options [nop,nop,TS = val 442166724 ecr 4130741282], length 1448=0A= 00:00:02.134245 IP (tos 0x8, ttl 63, id 44792, offset 0, flags [DF], = proto TCP (6), length 64)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741282 ecr 442166723,nop,nop,sack 1 {115900520:115920352}], length 0=0A= 00:00:02.134249 IP (tos 0x8, ttl 64, id 47152, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115946920:115948368, ack 50481, win 130, options [nop,nop,TS = val 442166724 ecr 4130741282], length 1448=0A= 00:00:02.134252 IP (tos 0x8, ttl 63, id 44793, offset 0, flags [DF], = proto TCP (6), length 64)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741282 ecr 442166723,nop,nop,sack 1 {115900520:115921800}], length 0=0A= 00:00:02.134256 IP (tos 0x8, ttl 64, id 47153, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115948368:115949816, ack 50481, win 130, options [nop,nop,TS = val 442166724 ecr 4130741282], length 1448=0A= 00:00:02.134311 IP (tos 0x8, ttl 63, id 44794, offset 0, flags [DF], = proto TCP (6), length 64)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741282 ecr 442166723,nop,nop,sack 1 {115900520:115923248}], length 0=0A= 00:00:02.134317 IP (tos 0x8, ttl 64, id 47154, offset 0, flags [DF], = proto TCP (6), length 556)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [P.], seq 115949816:115950320, ack 50481, win 130, options [nop,nop,TS = val 442166724 ecr 4130741282], length 504=0A= 00:00:02.134320 IP (tos 0x8, ttl 63, id 44795, offset 0, flags [DF], = proto TCP (6), length 64)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741282 ecr 442166723,nop,nop,sack 1 {115900520:115924696}], length 0=0A= 00:00:02.134322 IP (tos 0x8, ttl 63, id 44796, offset 0, flags [DF], = proto TCP (6), length 64)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741282 ecr 442166723,nop,nop,sack 1 {115900520:115926144}], length 0=0A= 00:00:02.134325 IP (tos 0x8, ttl 63, id 44797, offset 0, flags [DF], = proto TCP (6), length 64)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741282 ecr 442166723,nop,nop,sack 1 {115900520:115927592}], length 0=0A= 00:00:02.134328 IP (tos 0x8, ttl 63, id 44798, offset 0, flags [DF], = proto TCP (6), length 64)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741282 ecr 442166723,nop,nop,sack 1 {115900520:115929040}], length 0=0A= 00:00:02.134330 IP (tos 0x8, ttl 63, id 44799, offset 0, flags [DF], = proto TCP (6), length 64)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741282 ecr 442166723,nop,nop,sack 1 {115900520:115930488}], length 0=0A= 00:00:02.134387 IP bad-len 0=0A= 00:00:02.134437 IP (tos 0x8, ttl 63, id 44800, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741282 ecr 442166723,nop,nop,sack 2 = {115931936:115933384}{115900520:115930488}], length 0=0A= 00:00:02.134448 IP (tos 0x8, ttl 64, id 47156, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115930488:115931936, ack 50481, win 130, options [nop,nop,TS = val 442166724 ecr 4130741282], length 1448=0A= 00:00:02.134451 IP (tos 0x8, ttl 63, id 44801, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741282 ecr 442166723,nop,nop,sack 2 = {115931936:115933888}{115900520:115930488}], length 0=0A= 00:00:02.134456 IP (tos 0x8, ttl 64, id 47157, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115958504:115959952, ack 50481, win 130, options [nop,nop,TS = val 442166724 ecr 4130741282], length 1448=0A= 00:00:02.134460 IP (tos 0x8, ttl 63, id 44802, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741282 ecr 442166723,nop,nop,sack 2 = {115931936:115935336}{115900520:115930488}], length 0=0A= 00:00:02.134464 IP (tos 0x8, ttl 64, id 47158, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115959952:115961400, ack 50481, win 130, options [nop,nop,TS = val 442166724 ecr 4130741282], length 1448=0A= 00:00:02.134467 IP (tos 0x8, ttl 63, id 44803, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741282 ecr 442166723,nop,nop,sack 2 = {115931936:115936784}{115900520:115930488}], length 0=0A= 00:00:02.134472 IP (tos 0x8, ttl 64, id 47159, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115961400:115962848, ack 50481, win 130, options [nop,nop,TS = val 442166724 ecr 4130741282], length 1448=0A= 00:00:02.134475 IP (tos 0x8, ttl 63, id 44804, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115938232}{115900520:115930488}], length 0=0A= 00:00:02.134479 IP (tos 0x8, ttl 64, id 47160, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115962848:115964296, ack 50481, win 130, options [nop,nop,TS = val 442166724 ecr 4130741283], length 1448=0A= 00:00:02.134482 IP (tos 0x8, ttl 63, id 44805, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115939680}{115900520:115930488}], length 0=0A= 00:00:02.134487 IP (tos 0x8, ttl 64, id 47161, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115964296:115965744, ack 50481, win 130, options [nop,nop,TS = val 442166724 ecr 4130741283], length 1448=0A= 00:00:02.134490 IP (tos 0x8, ttl 63, id 44806, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115941128}{115900520:115930488}], length 0=0A= 00:00:02.134495 IP (tos 0x8, ttl 64, id 47162, offset 0, flags [DF], = proto TCP (6), length 1060)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [P.], seq 115965744:115966752, ack 50481, win 130, options [nop,nop,TS = val 442166724 ecr 4130741283], length 1008=0A= 00:00:02.134498 IP (tos 0x8, ttl 63, id 44807, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115942576}{115900520:115930488}], length 0=0A= 00:00:02.134500 IP (tos 0x8, ttl 63, id 44808, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134503 IP (tos 0x8, ttl 63, id 44809, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134506 IP (tos 0x8, ttl 63, id 44810, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134508 IP (tos 0x8, ttl 63, id 44811, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134511 IP (tos 0x8, ttl 63, id 44812, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134514 IP (tos 0x8, ttl 63, id 44813, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134561 IP (tos 0x8, ttl 63, id 44814, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134564 IP (tos 0x8, ttl 63, id 44815, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134567 IP (tos 0x8, ttl 63, id 44816, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134570 IP (tos 0x8, ttl 63, id 44817, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134572 IP (tos 0x8, ttl 63, id 44818, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134625 IP bad-len 0=0A= 00:00:02.134641 IP (tos 0x8, ttl 64, id 47164, offset 0, flags [DF], = proto TCP (6), length 1172)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [P.], seq 115982064:115983184, ack 50481, win 130, options [nop,nop,TS = val 442166725 ecr 4130741283], length 1120=0A= 00:00:02.134688 IP (tos 0x8, ttl 63, id 44819, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134693 IP (tos 0x8, ttl 63, id 44820, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134696 IP (tos 0x8, ttl 63, id 44821, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134698 IP (tos 0x8, ttl 63, id 44822, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134701 IP (tos 0x8, ttl 63, id 44823, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134704 IP (tos 0x8, ttl 63, id 44824, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134707 IP (tos 0x8, ttl 63, id 44825, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134709 IP (tos 0x8, ttl 63, id 44826, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134811 IP (tos 0x8, ttl 63, id 44827, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134814 IP (tos 0x8, ttl 63, id 44828, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134817 IP (tos 0x8, ttl 63, id 44829, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134820 IP (tos 0x8, ttl 63, id 44830, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134823 IP (tos 0x8, ttl 63, id 44831, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134825 IP (tos 0x8, ttl 63, id 44832, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134868 IP bad-len 0=0A= 00:00:02.134937 IP (tos 0x8, ttl 63, id 44833, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134941 IP (tos 0x8, ttl 63, id 44834, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134944 IP (tos 0x8, ttl 63, id 44835, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134947 IP (tos 0x8, ttl 63, id 44836, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134950 IP (tos 0x8, ttl 63, id 44837, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134953 IP (tos 0x8, ttl 63, id 44838, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.135061 IP (tos 0x8, ttl 63, id 44839, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.135065 IP (tos 0x8, ttl 63, id 44840, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.363636 IP (tos 0x8, ttl 64, id 47295, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115899072:115900520, ack 50481, win 130, options [nop,nop,TS = val 442166954 ecr 4130741283], length 1448=0A= 00:00:02.363810 IP (tos 0x8, ttl 63, id 44855, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741511 ecr 442166954,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.623642 IP (tos 0x8, ttl 64, id 47501, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115899072:115900520, ack 50481, win 130, options [nop,nop,TS = val 442167214 ecr 4130741511], length 1448=0A= 00:00:02.623790 IP (tos 0x8, ttl 63, id 44870, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741770 ecr 442167214,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.943842 IP (tos 0x8, ttl 64, id 47767, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115899072:115900520, ack 50481, win 130, options [nop,nop,TS = val 442167534 ecr 4130741770], length 1448=0A= 00:00:02.943987 IP (tos 0x8, ttl 63, id 44888, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130742090 ecr 442167534,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:03.383654 IP (tos 0x8, ttl 64, id 48161, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115899072:115900520, ack 50481, win 130, options [nop,nop,TS = val 442167974 ecr 4130742090], length 1448=0A= 00:00:03.383867 IP (tos 0x8, ttl 63, id 44913, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130742528 ecr 442167974,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:04.063674 IP (tos 0x8, ttl 64, id 50072, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115899072:115900520, ack 50481, win 130, options [nop,nop,TS = val 442168654 ecr 4130742528], length 1448=0A= 00:00:04.063865 IP (tos 0x8, ttl 63, id 44951, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130743206 ecr 442168654,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:05.223693 IP (tos 0x8, ttl 64, id 50946, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115899072:115900520, ack 50481, win 130, options [nop,nop,TS = val 442169814 ecr 4130743206], length 1448=0A= 00:00:05.223844 IP (tos 0x8, ttl 63, id 45015, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130744363 ecr 442169814,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:07.343740 IP (tos 0x8, ttl 64, id 52995, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115899072:115900520, ack 50481, win 130, options [nop,nop,TS = val 442171934 ecr 4130744363], length 1448=0A= 00:00:07.343915 IP (tos 0x8, ttl 63, id 45129, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130746477 ecr 442171934,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:11.383824 IP (tos 0x8, ttl 64, id 56560, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115899072:115900520, ack 50481, win 130, options [nop,nop,TS = val 442175974 ecr 4130746477], length 1448=0A= 00:00:11.384041 IP (tos 0x8, ttl 63, id 45349, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130750505 ecr 442175974,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:19.263992 IP (tos 0x8, ttl 64, id 64902, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115899072:115900520, ack 50481, win 130, options [nop,nop,TS = val 442183854 ecr 4130750505], length 1448=0A= 00:00:19.264158 IP (tos 0x8, ttl 63, id 45780, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130758362 ecr 442183854,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:34.824322 IP (tos 0x8, ttl 64, id 15028, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115899072:115900520, ack 50481, win 130, options [nop,nop,TS = val 442199414 ecr 4130758362], length 1448=0A= 00:00:34.824502 IP (tos 0x8, ttl 63, id 46610, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130773876 ecr 442199414,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:50.384652 IP (tos 0x8, ttl 64, id 29375, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115899072:115900520, ack 50481, win 130, options [nop,nop,TS = val 442214974 ecr 4130773876], length 1448=0A= 00:00:50.384844 IP (tos 0x8, ttl 63, id 47495, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130789390 ecr 442214974,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:01:05.944983 IP (tos 0x8, ttl 64, id 50803, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115899072:115900520, ack 50481, win 130, options [nop,nop,TS = val 442230534 ecr 4130789390], length 1448=0A= 00:01:05.945186 IP (tos 0x8, ttl 63, id 48429, offset 0, flags [DF], = proto TCP (6), length 64)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115930488, win 5271, options [nop,nop,TS val = 4130804905 ecr 442230534,nop,nop,sack 1 {115931936:115944024}], length 0=0A= 00:01:05.945209 IP bad-len 0=0A= 00:01:05.945214 IP (tos 0x8, ttl 63, id 48430, offset 0, flags [DF], = proto TCP (6), length 64)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115930488, win 6295, options [nop,nop,TS val = 4130804905 ecr 442230534,nop,nop,sack 1 {115931936:115944024}], length 0=0A= 00:01:05.945435 IP (tos 0x8, ttl 63, id 48431, offset 0, flags [DF], = proto TCP (6), length 52)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115944024, win 5449, options [nop,nop,TS val = 4130804905 ecr 442230534], length 0=0A= 00:01:05.945444 IP bad-len 0=0A= 00:01:05.945449 IP (tos 0x8, ttl 63, id 48432, offset 0, flags [DF], = proto TCP (6), length 52)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115944024, win 5449, options [nop,nop,TS val = 4130804905 ecr 442230534], length 0=0A= 00:01:05.945455 IP (tos 0x8, ttl 64, id 50806, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115948368:115949816, ack 50481, win 130, options [nop,nop,TS = val 442230534 ecr 4130804905], length 1448=0A= 00:01:05.945458 IP (tos 0x8, ttl 63, id 48433, offset 0, flags [DF], = proto TCP (6), length 52)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115944024, win 6473, options [nop,nop,TS val = 4130804905 ecr 442230534], length 0=0A= 00:01:05.945685 IP (tos 0x8, ttl 63, id 48434, offset 0, flags [DF], = proto TCP (6), length 52)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115946920, win 6292, options [nop,nop,TS val = 4130804905 ecr 442230534], length 0 ------=_NextPart_000_037F_01CC4545.0BE2BA90 Content-Type: text/plain; format=flowed; name="target-pcap-snip.txt"; reply-type=original Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="target-pcap-snip.txt" 00:00:02.134846 IP (tos 0x8, ttl 64, id 44837, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134848 IP (tos 0x8, ttl 63, id 47164, offset 0, flags [DF], = proto TCP (6), length 1172)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [P.], seq 115982064:115983184, ack 50481, win 130, options [nop,nop,TS = val 442166725 ecr 4130741283], length 1120=0A= 00:00:02.134856 IP (tos 0x8, ttl 64, id 44838, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134953 IP (tos 0x8, ttl 63, id 47165, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115983184:115984632, ack 50481, win 130, options [nop,nop,TS = val 442166725 ecr 4130741283], length 1448=0A= 00:00:02.134959 IP (tos 0x8, ttl 64, id 44839, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.134978 IP (tos 0x8, ttl 63, id 47166, offset 0, flags [DF], = proto TCP (6), length 1436)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115984632:115986016, ack 50481, win 130, options [nop,nop,TS = val 442166725 ecr 4130741283], length 1384=0A= 00:00:02.134985 IP (tos 0x8, ttl 64, id 44840, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741283 ecr 442166723,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.363721 IP (tos 0x8, ttl 63, id 47295, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115899072:115900520, ack 50481, win 130, options [nop,nop,TS = val 442166954 ecr 4130741283], length 1448=0A= 00:00:02.363732 IP (tos 0x8, ttl 64, id 44855, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741511 ecr 442166954,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.623728 IP (tos 0x8, ttl 63, id 47501, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115899072:115900520, ack 50481, win 130, options [nop,nop,TS = val 442167214 ecr 4130741511], length 1448=0A= 00:00:02.623745 IP (tos 0x8, ttl 64, id 44870, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130741770 ecr 442167214,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:02.943922 IP (tos 0x8, ttl 63, id 47767, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115899072:115900520, ack 50481, win 130, options [nop,nop,TS = val 442167534 ecr 4130741770], length 1448=0A= 00:00:02.943937 IP (tos 0x8, ttl 64, id 44888, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130742090 ecr 442167534,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:03.383742 IP (tos 0x8, ttl 63, id 48161, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115899072:115900520, ack 50481, win 130, options [nop,nop,TS = val 442167974 ecr 4130742090], length 1448=0A= 00:00:03.383759 IP (tos 0x8, ttl 64, id 44913, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130742528 ecr 442167974,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:04.063762 IP (tos 0x8, ttl 63, id 50072, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115899072:115900520, ack 50481, win 130, options [nop,nop,TS = val 442168654 ecr 4130742528], length 1448=0A= 00:00:04.063782 IP (tos 0x8, ttl 64, id 44951, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130743206 ecr 442168654,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:05.223784 IP (tos 0x8, ttl 63, id 50946, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115899072:115900520, ack 50481, win 130, options [nop,nop,TS = val 442169814 ecr 4130743206], length 1448=0A= 00:00:05.223802 IP (tos 0x8, ttl 64, id 45015, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130744363 ecr 442169814,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:07.343828 IP (tos 0x8, ttl 63, id 52995, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115899072:115900520, ack 50481, win 130, options [nop,nop,TS = val 442171934 ecr 4130744363], length 1448=0A= 00:00:07.343843 IP (tos 0x8, ttl 64, id 45129, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130746477 ecr 442171934,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:11.383916 IP (tos 0x8, ttl 63, id 56560, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115899072:115900520, ack 50481, win 130, options [nop,nop,TS = val 442175974 ecr 4130746477], length 1448=0A= 00:00:11.383929 IP (tos 0x8, ttl 64, id 45349, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130750505 ecr 442175974,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:19.264089 IP (tos 0x8, ttl 63, id 64902, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115899072:115900520, ack 50481, win 130, options [nop,nop,TS = val 442183854 ecr 4130750505], length 1448=0A= 00:00:19.264102 IP (tos 0x8, ttl 64, id 45780, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130758362 ecr 442183854,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:34.824431 IP (tos 0x8, ttl 63, id 15028, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115899072:115900520, ack 50481, win 130, options [nop,nop,TS = val 442199414 ecr 4130758362], length 1448=0A= 00:00:34.824443 IP (tos 0x8, ttl 64, id 46610, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130773876 ecr 442199414,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:00:50.384774 IP (tos 0x8, ttl 63, id 29375, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115899072:115900520, ack 50481, win 130, options [nop,nop,TS = val 442214974 ecr 4130773876], length 1448=0A= 00:00:50.384787 IP (tos 0x8, ttl 64, id 47495, offset 0, flags [DF], = proto TCP (6), length 72)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115899072, win 7235, options [nop,nop,TS val = 4130789390 ecr 442214974,nop,nop,sack 2 = {115931936:115944024}{115900520:115930488}], length 0=0A= 00:01:05.945115 IP (tos 0x8, ttl 63, id 50803, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115899072:115900520, ack 50481, win 130, options [nop,nop,TS = val 442230534 ecr 4130789390], length 1448=0A= 00:01:05.945151 IP (tos 0x8, ttl 64, id 48429, offset 0, flags [DF], = proto TCP (6), length 64)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115930488, win 5271, options [nop,nop,TS val = 4130804905 ecr 442230534,nop,nop,sack 1 {115931936:115944024}], length 0=0A= 00:01:05.945177 IP (tos 0x8, ttl 64, id 48430, offset 0, flags [DF], = proto TCP (6), length 64)=0A= amsbld16.multiplay.co.uk.ssh > core0.nl.multiplay.co.uk.50096: Flags = [.], seq 50481, ack 115930488, win 6295, options [nop,nop,TS val = 4130804905 ecr 442230534,nop,nop,sack 1 {115931936:115944024}], length 0=0A= 00:01:05.945341 IP (tos 0x8, ttl 63, id 50804, offset 0, flags [DF], = proto TCP (6), length 1500)=0A= core0.nl.multiplay.co.uk.50096 > amsbld16.multiplay.co.uk.ssh: Flags = [.], seq 115930488:115931936, ack 50481, win 130, options [nop,nop,TS = val 442230534 ecr 4130804905], length 1448=0A= 00:01:05.945352 IP (tos 0x8, ttl 64, id 48431, offset 0, flags [DF], = proto TCP (6), length 52) ------=_NextPart_000_037F_01CC4545.0BE2BA90-- From owner-freebsd-net@FreeBSD.ORG Mon Jul 18 14:21:30 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 3A703106564A for ; Mon, 18 Jul 2011 14:21:30 +0000 (UTC) (envelope-from kimabrandt@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mx1.freebsd.org (Postfix) with SMTP id 992E08FC13 for ; Mon, 18 Jul 2011 14:21:29 +0000 (UTC) Received: (qmail invoked by alias); 18 Jul 2011 14:21:28 -0000 Received: from unknown (EHLO [10.10.10.22]) [94.18.122.170] by mail.gmx.net (mp071) with SMTP; 18 Jul 2011 16:21:28 +0200 X-Authenticated: #32880209 X-Provags-ID: V01U2FsdGVkX192jt98Z8Z2dlP4OJojHr0DfGjblvsV1sFvU0VEET FplRtNMQp1MCEK Message-ID: <4E244166.2080104@gmx.de> Date: Mon, 18 Jul 2011 16:21:26 +0200 From: "Kim A. Brandt" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Kim A. Brandt" References: <4E243D8F.1020305@gmx.de> In-Reply-To: <4E243D8F.1020305@gmx.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010803020108030501030005" X-Y-GMX-Trusted: 0 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: CARP-interface fail-over in case required program fails. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Jul 2011 14:21:30 -0000 This is a cryptographically signed message in MIME format. --------------ms010803020108030501030005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I guess one could monitor (!?) the program and ``Force Failover of the Ma= ster''[1] in case of errors. Is this the preferred way of doing it, and i= f so what are common ways of monitoring programs and executing actions on= (monitor-)state changes? /Kim [1] http://www.openbsd.org/faq/pf/carp.html#forcefail On 2011-07-18 16:05, Kim A. Brandt wrote: > Hello list, > > is it possible to let a CARP-interface fail(-over) in the situation whe= n a certain program fails or stops working? I hope it's clear enough what= I have in mind. Could you give me any pointers on how this can be archiv= ed? > > /Kim --------------ms010803020108030501030005-- From owner-freebsd-net@FreeBSD.ORG Mon Jul 18 14:31: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 885291065670 for ; Mon, 18 Jul 2011 14:31:47 +0000 (UTC) (envelope-from kimabrandt@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mx1.freebsd.org (Postfix) with SMTP id 0D9238FC1C for ; Mon, 18 Jul 2011 14:31:46 +0000 (UTC) Received: (qmail invoked by alias); 18 Jul 2011 14:05:05 -0000 Received: from unknown (EHLO [10.10.10.22]) [94.18.122.170] by mail.gmx.net (mp007) with SMTP; 18 Jul 2011 16:05:05 +0200 X-Authenticated: #32880209 X-Provags-ID: V01U2FsdGVkX1+nE2Z1ZCunE5+gzW6Qyiq9a4ehG9eSdLOgt8gWuX q483R5/Lc4NN/B Message-ID: <4E243D8F.1020305@gmx.de> Date: Mon, 18 Jul 2011 16:05:03 +0200 From: "Kim A. Brandt" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060400000704050706070605" X-Y-GMX-Trusted: 0 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: CARP-interface fail-over in case required program fails. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Jul 2011 14:31:47 -0000 This is a cryptographically signed message in MIME format. --------------ms060400000704050706070605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hello list, is it possible to let a CARP-interface fail(-over) in the situation when = a certain program fails or stops working? I hope it's clear enough what I= have in mind. Could you give me any pointers on how this can be archived= ? /Kim --------------ms060400000704050706070605-- From owner-freebsd-net@FreeBSD.ORG Mon Jul 18 14:41:13 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 226E9106566B; Mon, 18 Jul 2011 14:41:13 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id D441E8FC16; Mon, 18 Jul 2011 14:41:12 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1QioQt-000MJQ-T9; Mon, 18 Jul 2011 17:04:28 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Jul 2011 17:04:27 +0300 From: Daniel Braniss Message-ID: Cc: freebsd-hackers@freebsd.org Subject: broadcast oddity X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Jul 2011 14:41:13 -0000 this code behaves correctly when run from a diskless host which booted via PXE, but fails on a host that was booted from disk. hint: the non working sends a packet with a non ethernet broadcast address and an ip address of 255.255.255.255, the working version sets the ethernet address to 0xffffffff and the ip to the network broadcast address. what am I doing wrong? danny PS: what is the correct way to obtain the network broadcast address? #include #include #include #include #include #include void bcast() { int so, on; char msg[BUFSIZ]; struct timespec t2; struct sockaddr_in soin; if((so = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0) { perror("socket"); exit(-1); } on = 1; if(setsockopt(so, SOL_SOCKET, SO_BROADCAST, &on, sizeof(on))) { perror("setsockopt"); exit(-1); } bzero(&soin, sizeof(struct sockaddr_in)); soin.sin_len = sizeof(struct sockaddr_in); soin.sin_family = AF_INET; soin.sin_addr.s_addr = INADDR_BROADCAST; soin.sin_port = htons(12345); while(1) { clock_gettime(CLOCK_REALTIME, &t2); sprintf(msg, "0x%016x", t2.tv_sec); if(sendto(so, msg, strlen(msg)+1, 0, (struct sockaddr *)&soin, sizeof(struct sockaddr)) < 0) { perror("sendto"); break; } sleep(10); } } main(int cc, char **vv) { bcast(); } From owner-freebsd-net@FreeBSD.ORG Mon Jul 18 15:18:56 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4DC5106564A for ; Mon, 18 Jul 2011 15:18:56 +0000 (UTC) (envelope-from d.banschikov@peterhost.ru) Received: from smtp.z8.ru (smtp.z8.ru [80.93.62.30]) by mx1.freebsd.org (Postfix) with ESMTP id 4C50D8FC08 for ; Mon, 18 Jul 2011 15:18:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=peterhost.ru; s=y2011-v1; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=tbpz2md5ZTAXtMlwJE96/xmm7XnVQIYRjMOoKp41PMs=; b=JD+59ysVD9gV48xv2M7MSnhOOVjyCaoSzbP9X4ZEG04EzTx6pGxwWJFY5dTQVFvgsiImuSIfojDDNiF1LwGBOFQbGwitfS3Mdb9j27sEej4a24LeLLBN6QijxxkWwxaxkXbbt8qPvoeI7YLK76HeZVKYRWbnu/EdIQaFSx1udcE=; Received: from [212.116.101.94] (helo=[10.10.32.3]) by smtp.z8.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Qipan-000OAG-8V for freebsd-net@freebsd.org; Mon, 18 Jul 2011 19:18:45 +0400 Message-ID: <4E244EDD.2000709@peterhost.ru> Date: Mon, 18 Jul 2011 19:18:53 +0400 From: Dmitry Banschikov User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Icedove/3.1.11 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4E243D8F.1020305@gmx.de> In-Reply-To: <4E243D8F.1020305@gmx.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030802070903090800090601" X-SA-Exim-Connect-IP: 212.116.101.94 X-SA-Exim-Mail-From: d.banschikov@peterhost.ru X-SA-Exim-Scanned: No (on smtp.z8.ru); SAEximRunCond expanded to false X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: CARP-interface fail-over in case required program fails. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Jul 2011 15:18:56 -0000 This is a cryptographically signed message in MIME format. --------------ms030802070903090800090601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 18.07.2011 18:05, Kim A. Brandt wrote: > Hello list, > > is it possible to let a CARP-interface fail(-over) in the situation whe= n > a certain program fails or stops working? I hope it's clear enough what= > I have in mind. Could you give me any pointers on how this can be archi= ved? > You can write simple script, which will monitor status of the program,=20 and if program fails, it can adjust advskew parameter of the CARP=20 interface forcing going interface to the backup state. --=20 Dmitry Banschikov --------------ms030802070903090800090601-- From owner-freebsd-net@FreeBSD.ORG Mon Jul 18 16:11:51 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F425106566B for ; Mon, 18 Jul 2011 16:11:51 +0000 (UTC) (envelope-from prvs=11805abe50=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 1C0ED8FC15 for ; Mon, 18 Jul 2011 16:11:43 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Mon, 18 Jul 2011 17:10:55 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 18 Jul 2011 17:10:55 +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 md50014209900.msg for ; Mon, 18 Jul 2011 17:10:55 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=11805abe50=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <22837855EB8D495BB30524767F04B5FF@multiplay.co.uk> From: "Steven Hartland" To: "Steven Hartland" , "Kevin Oberman" , "Vogel, Jack" References: <379885BA631F4C7787C24E00A174B429@multiplay.co.uk> Date: Mon, 18 Jul 2011 17:11:18 +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 Cc: freebsd-net@freebsd.org Subject: Re: high bandwidth tcp connection stalls on igb (was: 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: Mon, 18 Jul 2011 16:11:51 -0000 Confirmed with blade to blade transfer. Also noticed that if two transfers are happening at the same time, both will stall, not just one, but ssh consoles don't seem to be effected only high volume transfers like scp and rsync. It also seems like the more active connections the more likely a stall will happen. Another thing I've noticed is the trace from the source host shows a large number of "TCP ACKed lost segment" interspersed by 8 - 16K IP packets starting just after the ssh handshake, when looking at the trace in wireshark, might this be relavent? I've tried with as many hardware options disabled as I could find, but no change -tso -rxcsum -txcsum -lro -vlanhwtag net.inet.tcp.tso=0 dev.igb.0.enable_aim=0 dev.igb.0.flow_control=0 dev.igb.1.enable_aim=0 dev.igb.1.flow_control=0 Here's the stats from the suspect device which has just stalled again Jack does anything look suspect here and do you have any ideas what this might be? dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 2.0.7 dev.igb.0.%driver: igb dev.igb.0.%location: slot=0 function=0 dev.igb.0.%pnpinfo: vendor=0x8086 device=0x10e7 subvendor=0x15d9 subdevice=0x10e7 class=0x020000 dev.igb.0.%parent: pci5 dev.igb.0.nvm: -1 dev.igb.0.flow_control: 0 dev.igb.0.enable_aim: 0 dev.igb.0.rx_processing_limit: 100 dev.igb.0.link_irq: 4 dev.igb.0.dropped: 0 dev.igb.0.tx_dma_fail: 0 dev.igb.0.rx_overruns: 0 dev.igb.0.watchdog_timeouts: 0 dev.igb.0.device_control: 14424641 dev.igb.0.rx_control: 67141634 dev.igb.0.interrupt_mask: 4 dev.igb.0.extended_int_mask: 2147484159 dev.igb.0.tx_buf_alloc: 0 dev.igb.0.rx_buf_alloc: 0 dev.igb.0.fc_high_water: 58976 dev.igb.0.fc_low_water: 58960 dev.igb.0.queue0.interrupt_rate: 8000 dev.igb.0.queue0.txd_head: 266 dev.igb.0.queue0.txd_tail: 266 dev.igb.0.queue0.no_desc_avail: 0 dev.igb.0.queue0.tx_packets: 9462610 dev.igb.0.queue0.rxd_head: 891 dev.igb.0.queue0.rxd_tail: 890 dev.igb.0.queue0.rx_packets: 15326075 dev.igb.0.queue0.rx_bytes: 19146964251 dev.igb.0.queue0.lro_queued: 0 dev.igb.0.queue0.lro_flushed: 0 dev.igb.0.queue1.interrupt_rate: 8000 dev.igb.0.queue1.txd_head: 225 dev.igb.0.queue1.txd_tail: 225 dev.igb.0.queue1.no_desc_avail: 0 dev.igb.0.queue1.tx_packets: 15985904 dev.igb.0.queue1.rxd_head: 999 dev.igb.0.queue1.rxd_tail: 998 dev.igb.0.queue1.rx_packets: 25696231 dev.igb.0.queue1.rx_bytes: 32902117763 dev.igb.0.queue1.lro_queued: 0 dev.igb.0.queue1.lro_flushed: 0 dev.igb.0.queue2.interrupt_rate: 8000 dev.igb.0.queue2.txd_head: 157 dev.igb.0.queue2.txd_tail: 157 dev.igb.0.queue2.no_desc_avail: 0 dev.igb.0.queue2.tx_packets: 12697405 dev.igb.0.queue2.rxd_head: 778 dev.igb.0.queue2.rxd_tail: 777 dev.igb.0.queue2.rx_packets: 20780810 dev.igb.0.queue2.rx_bytes: 26096219675 dev.igb.0.queue2.lro_queued: 0 dev.igb.0.queue2.lro_flushed: 0 dev.igb.0.queue3.interrupt_rate: 8000 dev.igb.0.queue3.txd_head: 242 dev.igb.0.queue3.txd_tail: 242 dev.igb.0.queue3.no_desc_avail: 0 dev.igb.0.queue3.tx_packets: 11831167 dev.igb.0.queue3.rxd_head: 111 dev.igb.0.queue3.rxd_tail: 110 dev.igb.0.queue3.rx_packets: 18590831 dev.igb.0.queue3.rx_bytes: 25894011731 dev.igb.0.queue3.lro_queued: 0 dev.igb.0.queue3.lro_flushed: 0 dev.igb.0.queue4.interrupt_rate: 8000 dev.igb.0.queue4.txd_head: 841 dev.igb.0.queue4.txd_tail: 841 dev.igb.0.queue4.no_desc_avail: 0 dev.igb.0.queue4.tx_packets: 13540958 dev.igb.0.queue4.rxd_head: 835 dev.igb.0.queue4.rxd_tail: 834 dev.igb.0.queue4.rx_packets: 21880643 dev.igb.0.queue4.rx_bytes: 28291440234 dev.igb.0.queue4.lro_queued: 0 dev.igb.0.queue4.lro_flushed: 0 dev.igb.0.queue5.interrupt_rate: 8000 dev.igb.0.queue5.txd_head: 941 dev.igb.0.queue5.txd_tail: 941 dev.igb.0.queue5.no_desc_avail: 0 dev.igb.0.queue5.tx_packets: 11124540 dev.igb.0.queue5.rxd_head: 214 dev.igb.0.queue5.rxd_tail: 213 dev.igb.0.queue5.rx_packets: 18048214 dev.igb.0.queue5.rx_bytes: 22957384083 dev.igb.0.queue5.lro_queued: 0 dev.igb.0.queue5.lro_flushed: 0 dev.igb.0.queue6.interrupt_rate: 8000 dev.igb.0.queue6.txd_head: 782 dev.igb.0.queue6.txd_tail: 783 dev.igb.0.queue6.no_desc_avail: 0 dev.igb.0.queue6.tx_packets: 13581988 dev.igb.0.queue6.rxd_head: 504 dev.igb.0.queue6.rxd_tail: 503 dev.igb.0.queue6.rx_packets: 21590520 dev.igb.0.queue6.rx_bytes: 29030489548 dev.igb.0.queue6.lro_queued: 0 dev.igb.0.queue6.lro_flushed: 0 dev.igb.0.queue7.interrupt_rate: 8000 dev.igb.0.queue7.txd_head: 961 dev.igb.0.queue7.txd_tail: 961 dev.igb.0.queue7.no_desc_avail: 0 dev.igb.0.queue7.tx_packets: 14163482 dev.igb.0.queue7.rxd_head: 38 dev.igb.0.queue7.rxd_tail: 37 dev.igb.0.queue7.rx_packets: 23149606 dev.igb.0.queue7.rx_bytes: 29114500225 dev.igb.0.queue7.lro_queued: 0 dev.igb.0.queue7.lro_flushed: 0 dev.igb.0.mac_stats.excess_coll: 0 dev.igb.0.mac_stats.single_coll: 0 dev.igb.0.mac_stats.multiple_coll: 0 dev.igb.0.mac_stats.late_coll: 0 dev.igb.0.mac_stats.collision_count: 0 dev.igb.0.mac_stats.symbol_errors: 0 dev.igb.0.mac_stats.sequence_errors: 0 dev.igb.0.mac_stats.defer_count: 0 dev.igb.0.mac_stats.missed_packets: 0 dev.igb.0.mac_stats.recv_no_buff: 0 dev.igb.0.mac_stats.recv_undersize: 0 dev.igb.0.mac_stats.recv_fragmented: 0 dev.igb.0.mac_stats.recv_oversize: 0 dev.igb.0.mac_stats.recv_jabber: 0 dev.igb.0.mac_stats.recv_errs: 0 dev.igb.0.mac_stats.crc_errs: 0 dev.igb.0.mac_stats.alignment_errs: 0 dev.igb.0.mac_stats.coll_ext_errs: 0 dev.igb.0.mac_stats.xon_recvd: 0 dev.igb.0.mac_stats.xon_txd: 0 dev.igb.0.mac_stats.xoff_recvd: 0 dev.igb.0.mac_stats.xoff_txd: 0 dev.igb.0.mac_stats.total_pkts_recvd: 165067073 dev.igb.0.mac_stats.good_pkts_recvd: 165062852 dev.igb.0.mac_stats.bcast_pkts_recvd: 7827 dev.igb.0.mac_stats.mcast_pkts_recvd: 20 dev.igb.0.mac_stats.rx_frames_64: 18346 dev.igb.0.mac_stats.rx_frames_65_127: 2395695 dev.igb.0.mac_stats.rx_frames_128_255: 6686114 dev.igb.0.mac_stats.rx_frames_256_511: 9501896 dev.igb.0.mac_stats.rx_frames_512_1023: 14475414 dev.igb.0.mac_stats.rx_frames_1024_1522: 131985387 dev.igb.0.mac_stats.good_octets_recvd: 214093372362 dev.igb.0.mac_stats.good_octets_txd: 7388817393 dev.igb.0.mac_stats.total_pkts_txd: 102387885 dev.igb.0.mac_stats.good_pkts_txd: 102387885 dev.igb.0.mac_stats.bcast_pkts_txd: 4 dev.igb.0.mac_stats.mcast_pkts_txd: 0 dev.igb.0.mac_stats.tx_frames_64: 662 dev.igb.0.mac_stats.tx_frames_65_127: 102263884 dev.igb.0.mac_stats.tx_frames_128_255: 44518 dev.igb.0.mac_stats.tx_frames_256_511: 25033 dev.igb.0.mac_stats.tx_frames_512_1023: 18188 dev.igb.0.mac_stats.tx_frames_1024_1522: 35600 dev.igb.0.mac_stats.tso_txd: 0 dev.igb.0.mac_stats.tso_ctx_fail: 0 dev.igb.0.interrupts.asserts: 27233325 dev.igb.0.interrupts.rx_pkt_timer: 165061054 dev.igb.0.interrupts.rx_abs_timer: 0 dev.igb.0.interrupts.tx_pkt_timer: 0 dev.igb.0.interrupts.tx_abs_timer: 165062852 dev.igb.0.interrupts.tx_queue_empty: 102387060 dev.igb.0.interrupts.tx_queue_min_thresh: 0 dev.igb.0.interrupts.rx_desc_min_thresh: 0 dev.igb.0.interrupts.rx_overrun: 0 dev.igb.0.host.breaker_tx_pkt: 0 dev.igb.0.host.host_tx_pkt_discard: 0 dev.igb.0.host.rx_pkt: 1798 dev.igb.0.host.breaker_rx_pkts: 0 dev.igb.0.host.breaker_rx_pkt_drop: 0 dev.igb.0.host.tx_good_pkt: 825 dev.igb.0.host.breaker_tx_pkt_drop: 0 dev.igb.0.host.rx_good_bytes: 214093406063 dev.igb.0.host.tx_good_bytes: 7388817393 dev.igb.0.host.length_errors: 0 dev.igb.0.host.serdes_violation_pkt: 0 dev.igb.0.host.header_redir_missed: 0 ----- Original Message ----- From: "Steven Hartland" To: "Kevin Oberman" Cc: Sent: Monday, July 18, 2011 12:20 PM Subject: Re: igb enable_aim or flow_control causing tcp stalls? > ----- Original Message ----- > From: "Kevin Oberman" >> >> 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. > > I've managed to get a capture from both ends but its doesn't really make too > much sense to me. You can clearly see the stall which starts at the 2.1 second > mark, and recovers at the 65 second mark but what's causing it is a mystery. > > I've attached what I believe is the relevant a snippet from each trace. > > At this point I believe I've eliminated aim and flow_control as these where > both off when this test was preformed > > Any advice would be appreciated. > > The layout for this test was:- > Source (7.0-RELEASE-p2 on em0) -> Cisco 6509 -> supermicro blade -> Target > (8.2-RELEASE on igb0) > > I'm going to try and eliminate the Cisco next by going from two blades > on the local supermicro blade switch. > > 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. -------------------------------------------------------------------------------- > _______________________________________________ > 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" ================================================ 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 Mon Jul 18 16:40:46 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C146D106564A for ; Mon, 18 Jul 2011 16:40:46 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 750C68FC08 for ; Mon, 18 Jul 2011 16:40:46 +0000 (UTC) Received: by vxg33 with SMTP id 33so3218333vxg.13 for ; Mon, 18 Jul 2011 09:40:45 -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=5i5rp1IxGnfmUmH5iY/0Pg7KCjMxcITVPHGt0TLOxoY=; b=IKyLDSulVU2CAu9PxNe1ZplZkp5RvserkZRSTpkyREV8v4VkoVCgp5g28ICkUoSeiG 8t+M+AlqGXe6B5FVdChdwhtOAEgfxacG1MIdrrTsY69voaD+75mjjw9+B02CAbcZ0/kL 1h3qobXQOI8SlK+bnaECITQr0XTx0owbqtcDE= MIME-Version: 1.0 Received: by 10.52.69.39 with SMTP id b7mr6068120vdu.264.1311007245572; Mon, 18 Jul 2011 09:40:45 -0700 (PDT) Received: by 10.52.187.66 with HTTP; Mon, 18 Jul 2011 09:40:45 -0700 (PDT) In-Reply-To: References: <379885BA631F4C7787C24E00A174B429@multiplay.co.uk> Date: Mon, 18 Jul 2011 09:40:45 -0700 Message-ID: From: Jack Vogel 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, Kevin Oberman 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: Mon, 18 Jul 2011 16:40:46 -0000 I have no idea... but as a matter of principle I would see if updating to later code, both OS and especially the driver, reproduces the issue. Our validation group often has Linux as a link partner in testing, which can be good and bad, it actually sometimes has problems that FBSD on both sides doesn't. Jack On Mon, Jul 18, 2011 at 4:20 AM, Steven Hartland wrote: > ----- Original Message ----- From: "Kevin Oberman" > >> >> 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. >> > > I've managed to get a capture from both ends but its doesn't really make > too > much sense to me. You can clearly see the stall which starts at the 2.1 > second > mark, and recovers at the 65 second mark but what's causing it is a > mystery. > > I've attached what I believe is the relevant a snippet from each trace. > > At this point I believe I've eliminated aim and flow_control as these where > both off when this test was preformed > > Any advice would be appreciated. > > The layout for this test was:- > Source (7.0-RELEASE-p2 on em0) -> Cisco 6509 -> supermicro blade -> Target > (8.2-RELEASE on igb0) > > I'm going to try and eliminate the Cisco next by going from two blades > on the local supermicro blade switch. > > 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. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Jul 18 16:47:32 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBF76106566B for ; Mon, 18 Jul 2011 16:47:32 +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 AD57C8FC08 for ; Mon, 18 Jul 2011 16:47:32 +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 p6IGlRq0047353; Mon, 18 Jul 2011 12:47:27 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4E2463B2.2060006@sentex.net> Date: Mon, 18 Jul 2011 12:47:46 -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: Steven Hartland References: <379885BA631F4C7787C24E00A174B429@multiplay.co.uk> In-Reply-To: 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, Kevin Oberman 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: Mon, 18 Jul 2011 16:47:33 -0000 On 7/18/2011 7:20 AM, Steven Hartland wrote: > > The layout for this test was:- > Source (7.0-RELEASE-p2 on em0) -> Cisco 6509 -> supermicro blade -> Target > (8.2-RELEASE on igb0) Perhaps this might fix your issue ? http://svnweb.freebsd.org/base?view=revision&revision=223675 It was MFC'd to RELENG_8 on June 29th ---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 Mon Jul 18 17:21: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 E9074106567D for ; Mon, 18 Jul 2011 17:21:29 +0000 (UTC) (envelope-from fodillemlinkarim@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 A2F7C8FC17 for ; Mon, 18 Jul 2011 17:21:29 +0000 (UTC) Received: by vws18 with SMTP id 18so3247052vws.13 for ; Mon, 18 Jul 2011 10:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Mup2NJ+yre6E2zSzijYn/QGiRXBC8/e7BSyOkityBUA=; b=k9he5MuGi8+9/Oy4JEJM4ScIYYdGljI8vwg4HT5ZWl0TsY2+S2Gl/ypPS0RKvusL1G Zzuv+PGVpsbgvVVV9oYg8pcdPYVKHrPYcOfkzmF/6FGD00634WZOvEOTajrR/ro4KLSe /SrstgbSZYcDEGiY6GRKw+LnzaUe+dZuqq+ZU= Received: by 10.52.184.97 with SMTP id et1mr6413138vdc.458.1311007948331; Mon, 18 Jul 2011 09:52:28 -0700 (PDT) Received: from [192.168.1.71] ([208.85.112.101]) by mx.google.com with ESMTPS id z4sm1802291vcd.11.2011.07.18.09.52.26 (version=SSLv3 cipher=OTHER); Mon, 18 Jul 2011 09:52:27 -0700 (PDT) Message-ID: <4E2464C7.8070200@gmail.com> Date: Mon, 18 Jul 2011 12:52:23 -0400 From: Karim User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <379885BA631F4C7787C24E00A174B429@multiplay.co.uk> <22837855EB8D495BB30524767F04B5FF@multiplay.co.uk> In-Reply-To: <22837855EB8D495BB30524767F04B5FF@multiplay.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: high bandwidth tcp connection stalls on igb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Jul 2011 17:21:30 -0000 Hi Steven, On 11-07-18 12:11 PM, Steven Hartland wrote: > Confirmed with blade to blade transfer. Also noticed that if two > transfers are > happening at the same time, both will stall, not just one, but ssh > consoles > don't seem to be effected only high volume transfers like scp and rsync. > > It also seems like the more active connections the more likely a stall > will > happen. From the traces you sent it seems that the segment 115899072:115900520 is getting reject after the 3-dup acks and then the sender goes into retransmit timeout for several segments and the retransmit timeout backoff is what is causing the stall. Can you check the output of netstat -m on your machines when this happens (look for mbuf clusters denied). You might also give it a try with SACK turned off (net.inet.tcp.sack.enable=0). > > Another thing I've noticed is the trace from the source host shows a > large > number of "TCP ACKed lost segment" interspersed by 8 - 16K IP packets > starting > just after the ssh handshake, when looking at the trace in wireshark, > might > this be relavent? This is just a side effect of TSO being enabled on the same machine your doing captures on. The BPF filter is seeing large block of data to be segmented by your network interface. I hope this helps, Karim. > > I've tried with as many hardware options disabled as I could find, but > no change > -tso -rxcsum -txcsum -lro -vlanhwtag > net.inet.tcp.tso=0 > dev.igb.0.enable_aim=0 > dev.igb.0.flow_control=0 > dev.igb.1.enable_aim=0 > dev.igb.1.flow_control=0 > > Here's the stats from the suspect device which has just stalled again > Jack does > anything look suspect here and do you have any ideas what this might be? > > > dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 2.0.7 > dev.igb.0.%driver: igb > dev.igb.0.%location: slot=0 function=0 > dev.igb.0.%pnpinfo: vendor=0x8086 device=0x10e7 subvendor=0x15d9 > subdevice=0x10e7 class=0x020000 > dev.igb.0.%parent: pci5 > dev.igb.0.nvm: -1 > dev.igb.0.flow_control: 0 > dev.igb.0.enable_aim: 0 > dev.igb.0.rx_processing_limit: 100 > dev.igb.0.link_irq: 4 > dev.igb.0.dropped: 0 > dev.igb.0.tx_dma_fail: 0 > dev.igb.0.rx_overruns: 0 > dev.igb.0.watchdog_timeouts: 0 > dev.igb.0.device_control: 14424641 > dev.igb.0.rx_control: 67141634 > dev.igb.0.interrupt_mask: 4 > dev.igb.0.extended_int_mask: 2147484159 > dev.igb.0.tx_buf_alloc: 0 > dev.igb.0.rx_buf_alloc: 0 > dev.igb.0.fc_high_water: 58976 > dev.igb.0.fc_low_water: 58960 > dev.igb.0.queue0.interrupt_rate: 8000 > dev.igb.0.queue0.txd_head: 266 > dev.igb.0.queue0.txd_tail: 266 > dev.igb.0.queue0.no_desc_avail: 0 > dev.igb.0.queue0.tx_packets: 9462610 > dev.igb.0.queue0.rxd_head: 891 > dev.igb.0.queue0.rxd_tail: 890 > dev.igb.0.queue0.rx_packets: 15326075 > dev.igb.0.queue0.rx_bytes: 19146964251 > dev.igb.0.queue0.lro_queued: 0 > dev.igb.0.queue0.lro_flushed: 0 > dev.igb.0.queue1.interrupt_rate: 8000 > dev.igb.0.queue1.txd_head: 225 > dev.igb.0.queue1.txd_tail: 225 > dev.igb.0.queue1.no_desc_avail: 0 > dev.igb.0.queue1.tx_packets: 15985904 > dev.igb.0.queue1.rxd_head: 999 > dev.igb.0.queue1.rxd_tail: 998 > dev.igb.0.queue1.rx_packets: 25696231 > dev.igb.0.queue1.rx_bytes: 32902117763 > dev.igb.0.queue1.lro_queued: 0 > dev.igb.0.queue1.lro_flushed: 0 > dev.igb.0.queue2.interrupt_rate: 8000 > dev.igb.0.queue2.txd_head: 157 > dev.igb.0.queue2.txd_tail: 157 > dev.igb.0.queue2.no_desc_avail: 0 > dev.igb.0.queue2.tx_packets: 12697405 > dev.igb.0.queue2.rxd_head: 778 > dev.igb.0.queue2.rxd_tail: 777 > dev.igb.0.queue2.rx_packets: 20780810 > dev.igb.0.queue2.rx_bytes: 26096219675 > dev.igb.0.queue2.lro_queued: 0 > dev.igb.0.queue2.lro_flushed: 0 > dev.igb.0.queue3.interrupt_rate: 8000 > dev.igb.0.queue3.txd_head: 242 > dev.igb.0.queue3.txd_tail: 242 > dev.igb.0.queue3.no_desc_avail: 0 > dev.igb.0.queue3.tx_packets: 11831167 > dev.igb.0.queue3.rxd_head: 111 > dev.igb.0.queue3.rxd_tail: 110 > dev.igb.0.queue3.rx_packets: 18590831 > dev.igb.0.queue3.rx_bytes: 25894011731 > dev.igb.0.queue3.lro_queued: 0 > dev.igb.0.queue3.lro_flushed: 0 > dev.igb.0.queue4.interrupt_rate: 8000 > dev.igb.0.queue4.txd_head: 841 > dev.igb.0.queue4.txd_tail: 841 > dev.igb.0.queue4.no_desc_avail: 0 > dev.igb.0.queue4.tx_packets: 13540958 > dev.igb.0.queue4.rxd_head: 835 > dev.igb.0.queue4.rxd_tail: 834 > dev.igb.0.queue4.rx_packets: 21880643 > dev.igb.0.queue4.rx_bytes: 28291440234 > dev.igb.0.queue4.lro_queued: 0 > dev.igb.0.queue4.lro_flushed: 0 > dev.igb.0.queue5.interrupt_rate: 8000 > dev.igb.0.queue5.txd_head: 941 > dev.igb.0.queue5.txd_tail: 941 > dev.igb.0.queue5.no_desc_avail: 0 > dev.igb.0.queue5.tx_packets: 11124540 > dev.igb.0.queue5.rxd_head: 214 > dev.igb.0.queue5.rxd_tail: 213 > dev.igb.0.queue5.rx_packets: 18048214 > dev.igb.0.queue5.rx_bytes: 22957384083 > dev.igb.0.queue5.lro_queued: 0 > dev.igb.0.queue5.lro_flushed: 0 > dev.igb.0.queue6.interrupt_rate: 8000 > dev.igb.0.queue6.txd_head: 782 > dev.igb.0.queue6.txd_tail: 783 > dev.igb.0.queue6.no_desc_avail: 0 > dev.igb.0.queue6.tx_packets: 13581988 > dev.igb.0.queue6.rxd_head: 504 > dev.igb.0.queue6.rxd_tail: 503 > dev.igb.0.queue6.rx_packets: 21590520 > dev.igb.0.queue6.rx_bytes: 29030489548 > dev.igb.0.queue6.lro_queued: 0 > dev.igb.0.queue6.lro_flushed: 0 > dev.igb.0.queue7.interrupt_rate: 8000 > dev.igb.0.queue7.txd_head: 961 > dev.igb.0.queue7.txd_tail: 961 > dev.igb.0.queue7.no_desc_avail: 0 > dev.igb.0.queue7.tx_packets: 14163482 > dev.igb.0.queue7.rxd_head: 38 > dev.igb.0.queue7.rxd_tail: 37 > dev.igb.0.queue7.rx_packets: 23149606 > dev.igb.0.queue7.rx_bytes: 29114500225 > dev.igb.0.queue7.lro_queued: 0 > dev.igb.0.queue7.lro_flushed: 0 > dev.igb.0.mac_stats.excess_coll: 0 > dev.igb.0.mac_stats.single_coll: 0 > dev.igb.0.mac_stats.multiple_coll: 0 > dev.igb.0.mac_stats.late_coll: 0 > dev.igb.0.mac_stats.collision_count: 0 > dev.igb.0.mac_stats.symbol_errors: 0 > dev.igb.0.mac_stats.sequence_errors: 0 > dev.igb.0.mac_stats.defer_count: 0 > dev.igb.0.mac_stats.missed_packets: 0 > dev.igb.0.mac_stats.recv_no_buff: 0 > dev.igb.0.mac_stats.recv_undersize: 0 > dev.igb.0.mac_stats.recv_fragmented: 0 > dev.igb.0.mac_stats.recv_oversize: 0 > dev.igb.0.mac_stats.recv_jabber: 0 > dev.igb.0.mac_stats.recv_errs: 0 > dev.igb.0.mac_stats.crc_errs: 0 > dev.igb.0.mac_stats.alignment_errs: 0 > dev.igb.0.mac_stats.coll_ext_errs: 0 > dev.igb.0.mac_stats.xon_recvd: 0 > dev.igb.0.mac_stats.xon_txd: 0 > dev.igb.0.mac_stats.xoff_recvd: 0 > dev.igb.0.mac_stats.xoff_txd: 0 > dev.igb.0.mac_stats.total_pkts_recvd: 165067073 > dev.igb.0.mac_stats.good_pkts_recvd: 165062852 > dev.igb.0.mac_stats.bcast_pkts_recvd: 7827 > dev.igb.0.mac_stats.mcast_pkts_recvd: 20 > dev.igb.0.mac_stats.rx_frames_64: 18346 > dev.igb.0.mac_stats.rx_frames_65_127: 2395695 > dev.igb.0.mac_stats.rx_frames_128_255: 6686114 > dev.igb.0.mac_stats.rx_frames_256_511: 9501896 > dev.igb.0.mac_stats.rx_frames_512_1023: 14475414 > dev.igb.0.mac_stats.rx_frames_1024_1522: 131985387 > dev.igb.0.mac_stats.good_octets_recvd: 214093372362 > dev.igb.0.mac_stats.good_octets_txd: 7388817393 > dev.igb.0.mac_stats.total_pkts_txd: 102387885 > dev.igb.0.mac_stats.good_pkts_txd: 102387885 > dev.igb.0.mac_stats.bcast_pkts_txd: 4 > dev.igb.0.mac_stats.mcast_pkts_txd: 0 > dev.igb.0.mac_stats.tx_frames_64: 662 > dev.igb.0.mac_stats.tx_frames_65_127: 102263884 > dev.igb.0.mac_stats.tx_frames_128_255: 44518 > dev.igb.0.mac_stats.tx_frames_256_511: 25033 > dev.igb.0.mac_stats.tx_frames_512_1023: 18188 > dev.igb.0.mac_stats.tx_frames_1024_1522: 35600 > dev.igb.0.mac_stats.tso_txd: 0 > dev.igb.0.mac_stats.tso_ctx_fail: 0 > dev.igb.0.interrupts.asserts: 27233325 > dev.igb.0.interrupts.rx_pkt_timer: 165061054 > dev.igb.0.interrupts.rx_abs_timer: 0 > dev.igb.0.interrupts.tx_pkt_timer: 0 > dev.igb.0.interrupts.tx_abs_timer: 165062852 > dev.igb.0.interrupts.tx_queue_empty: 102387060 > dev.igb.0.interrupts.tx_queue_min_thresh: 0 > dev.igb.0.interrupts.rx_desc_min_thresh: 0 > dev.igb.0.interrupts.rx_overrun: 0 > dev.igb.0.host.breaker_tx_pkt: 0 > dev.igb.0.host.host_tx_pkt_discard: 0 > dev.igb.0.host.rx_pkt: 1798 > dev.igb.0.host.breaker_rx_pkts: 0 > dev.igb.0.host.breaker_rx_pkt_drop: 0 > dev.igb.0.host.tx_good_pkt: 825 > dev.igb.0.host.breaker_tx_pkt_drop: 0 > dev.igb.0.host.rx_good_bytes: 214093406063 > dev.igb.0.host.tx_good_bytes: 7388817393 > dev.igb.0.host.length_errors: 0 > dev.igb.0.host.serdes_violation_pkt: 0 > dev.igb.0.host.header_redir_missed: 0 > > ----- Original Message ----- From: "Steven Hartland" > > To: "Kevin Oberman" > Cc: > Sent: Monday, July 18, 2011 12:20 PM > Subject: Re: igb enable_aim or flow_control causing tcp stalls? > > >> ----- Original Message ----- From: "Kevin Oberman" >>> >>> 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. >> >> I've managed to get a capture from both ends but its doesn't really >> make too >> much sense to me. You can clearly see the stall which starts at the >> 2.1 second >> mark, and recovers at the 65 second mark but what's causing it is a >> mystery. >> >> I've attached what I believe is the relevant a snippet from each trace. >> >> At this point I believe I've eliminated aim and flow_control as these >> where >> both off when this test was preformed >> >> Any advice would be appreciated. >> >> The layout for this test was:- >> Source (7.0-RELEASE-p2 on em0) -> Cisco 6509 -> supermicro blade -> >> Target >> (8.2-RELEASE on igb0) >> >> I'm going to try and eliminate the Cisco next by going from two blades >> on the local supermicro blade switch. >> >> 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. > > > -------------------------------------------------------------------------------- > > > >> _______________________________________________ >> 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" > > > ================================================ > 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. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Jul 18 17:54: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 84D58106564A; Mon, 18 Jul 2011 17:54:33 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5466F8FC16; Mon, 18 Jul 2011 17:54:32 +0000 (UTC) Received: by pvg11 with SMTP id 11so4299434pvg.13 for ; Mon, 18 Jul 2011 10:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=tEUMLsCuN4FelOUg5wTWClp1MtclE8hHlyHQzPNJU/c=; b=TjwtpuHSFvN2jx/vs+EpeH0EVwPTM93TixaRMJSRmlQc3VJA+U/IP6rYOsWFzKMpKj RH/I22dyanDgGwC8XsmG5ngd8PbNJSnibyzflb3abY0d1uBQeq1Q+CMyld/vSNybYOPv cHfCpIVNUJNdZUcK2QCINnajR/oGasLOb62+c= Received: by 10.68.46.65 with SMTP id t1mr8861230pbm.231.1311009936691; Mon, 18 Jul 2011 10:25:36 -0700 (PDT) Received: from sidhe.local ([75.101.87.90]) by mx.google.com with ESMTPS id m7sm2560981pbk.70.2011.07.18.10.25.33 (version=SSLv3 cipher=OTHER); Mon, 18 Jul 2011 10:25:35 -0700 (PDT) Message-ID: <4E246C95.40601@gmail.com> Date: Mon, 18 Jul 2011 10:25:41 -0700 From: Matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110716 Thunderbird/5.0 MIME-Version: 1.0 To: ae@FreeBSD.org References: <201107140702.p6E721Y4012318@freefall.freebsd.org> In-Reply-To: <201107140702.p6E721Y4012318@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, freebsd-wireless@FreeBSD.org 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: Mon, 18 Jul 2011 17:54:33 -0000 On 07/14/11 00:02, ae@FreeBSD.org wrote: > 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 > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" > This is in progress...either from OpenBSD or from Alexandr's rt2860 code. Or a merge of the two. In the mean time, anyone interested should please test. It seems like it may not work on anything but current, but I don't have enough information to be sure. Patches (rt2860 merged with ral): https://docs.google.com/leaf?id=0B6YlMzJxarGbMWFmZDUxMTgtOTU4ZC00MjRlLThhMTctZTE1MDcwNDJiZDIx&hl=en_US If you have build errors, please provide output of uname -a, and copying exact error messages if any. Thanks, Matt From owner-freebsd-net@FreeBSD.ORG Mon Jul 18 20:47: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 DF3C8106566C; Mon, 18 Jul 2011 20:47:42 +0000 (UTC) (envelope-from rea@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 5C5838FC08; Mon, 18 Jul 2011 20:47:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codelabs.ru; s=two; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=sWXTlsCYLdFETDrReVLOeKJ90E8G+oDcJxLauJJ8d/I=; b=C1GTLWoNxgJcVMGnftbXINVDbcPUQId3lSvxNfu4ULnOwAhwsIYb0ASolz1yNQzLfrdqV0Pe+8W8XE5ynVjBhJanHASXMKY/tmCj0CHgieW6/WX2OY2e1pIsrtEKswEpNKl/dRuE4663Oc5ocFFiVXxcMUkyRMBNyzWOS/9w9MvWR/h60P57e7LzomZySYm3WNXgJRnbYYMX6FEqXFypCazZI7u6M7+wjyJFOPQmQYTeTUAZPLromtFysDIsbEBHIF+PKMeMnJtdx8Ah9fs3OFr3/PiAUnpJkXrs/cXZ1b2OcsIfR9lT/bceEdYzG1CnGbOxpY1Tv0OsW9n6jVA6VA==; Received: from MacBook-Eygene-Ryabinkin.local (ppp91-77-162-104.pppoe.mtu-net.ru [91.77.162.104]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1QiuUE-000DnR-2u; Tue, 19 Jul 2011 00:32:18 +0400 Date: Tue, 19 Jul 2011 00:32:15 +0400 From: Eygene Ryabinkin To: Daniel Braniss Message-ID: <20110718203215.GM54929@MacBook-Eygene-Ryabinkin.local> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="McpcKDxJRrEJVmOH" Content-Disposition: inline In-Reply-To: Sender: rea@codelabs.ru Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: broadcast oddity X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Jul 2011 20:47:43 -0000 --McpcKDxJRrEJVmOH Content-Type: multipart/mixed; boundary="UeXZ3FjlYZvuln/G" Content-Disposition: inline --UeXZ3FjlYZvuln/G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Daniel, good day. Mon, Jul 18, 2011 at 05:04:27PM +0300, Daniel Braniss wrote: > this code behaves correctly when run from a diskless host which > booted via PXE, but fails on a host that was booted from disk. > hint: the non working sends a packet with a non ethernet broadcast > address and an ip address of 255.255.255.255, And that non-broadcast ethernet address is the MAC of your default router? > the working version sets the ethernet address to 0xffffffff and the > ip to the network broadcast address. What's your routing table (netstat -rn) for the PXE-booted host? > what am I doing wrong? >=20 > danny > PS: what is the correct way to obtain the network broadcast address? You nailed it: you should send packets to the network's broadcast, not to the 0xffffffff. And in order to find the broadcast address for the interface (or network at that interface), you should use getifaddrs(), like in the attached example. It is very quick and dirty one and it has some limitations (e.g., it takes the first broadcast address from the interface), but it should be a good starting point. --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --UeXZ3FjlYZvuln/G Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bcast.c" #include #include #include #include #include #include #include #include #include void bcast(in_addr_t addr) { int so, on; char msg[BUFSIZ]; struct timespec t2; struct sockaddr_in soin; if((so = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0) { perror("socket"); exit(-1); } on = 1; if(setsockopt(so, SOL_SOCKET, SO_BROADCAST, &on, sizeof(on))) { perror("setsockopt"); exit(-1); } bzero(&soin, sizeof(struct sockaddr_in)); soin.sin_len = sizeof(struct sockaddr_in); soin.sin_family = AF_INET; soin.sin_addr.s_addr = addr; soin.sin_port = htons(12345); while(1) { clock_gettime(CLOCK_REALTIME, &t2); sprintf(msg, "0x%016x", t2.tv_sec); if(sendto(so, msg, strlen(msg)+1, 0, (struct sockaddr *)&soin, sizeof(struct sockaddr)) < 0) { perror("sendto"); break; } sleep(10); } } main(int argc, char *argv[]) { struct ifaddrs *ifap, *ifa, *our_if; struct sockaddr_in *sin; if (argc < 2) errx(1, "No arguments"); if (getifaddrs(&ifap) != 0) perror("getifaddrs"); our_if = NULL; for (ifa = ifap; ifa != NULL; ifa = ifa->ifa_next) { if (strcmp(argv[1], ifa->ifa_name) == 0) { sin = (struct sockaddr_in *)ifa->ifa_broadaddr; if (!(ifa->ifa_flags & IFF_BROADCAST) || sin == NULL || sin->sin_addr.s_addr == 0) continue; our_if = ifa; break; } } if (!our_if) errx(1, "Can't find broadcast-able interface '%s'", argv[1]); bcast(sin->sin_addr.s_addr); freeifaddrs(ifap); } --UeXZ3FjlYZvuln/G-- --McpcKDxJRrEJVmOH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iF0EAREIAAYFAk4kmE8ACgkQFq+eroFS7PvE+QD/ZL0cpFaKvLA+ZWWFH/QlA5Xb hqKEG+XY90zdya2/twEA9R3xcK8wwRtOiLf7Tb9SHviukeMsrxwufSWhdapJfj0= =Iujs -----END PGP SIGNATURE----- --McpcKDxJRrEJVmOH-- From owner-freebsd-net@FreeBSD.ORG Mon Jul 18 22:25:34 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8934E1065675 for ; Mon, 18 Jul 2011 22:25:34 +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 141038FC0A for ; Mon, 18 Jul 2011 22:25:33 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 8034215346D; Tue, 19 Jul 2011 00:25:32 +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 sakZaQPfkuM1; Tue, 19 Jul 2011 00:25:30 +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 1FCF115346C; Tue, 19 Jul 2011 00:25:30 +0200 (CEST) Message-ID: <4E24B2D9.3000706@digiware.nl> Date: Tue, 19 Jul 2011 00:25:29 +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> <4E2186A5.4040707@digiware.nl> In-Reply-To: <4E2186A5.4040707@digiware.nl> 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: Mon, 18 Jul 2011 22:25:34 -0000 On 16-7-2011 14:40, Willem Jan Withagen wrote: > 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. Just as a followup, it was indeed bad networking. One of the hubs building the 100Mb bit had thrown a fit, and decided to run things a mock. Taking it out, solved the matter. Now we're running again 100Mbit FTPs... --WjW From owner-freebsd-net@FreeBSD.ORG Mon Jul 18 23: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 18FC91065675 for ; Mon, 18 Jul 2011 23:10:57 +0000 (UTC) (envelope-from prvs=11805abe50=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 9383C8FC15 for ; Mon, 18 Jul 2011 23:10:56 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Tue, 19 Jul 2011 00:09:32 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 19 Jul 2011 00:09:32 +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 md50014214968.msg for ; Tue, 19 Jul 2011 00:09:31 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=11805abe50=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <5A1ACA29EDEC442BB5E14A375CBFF7A7@multiplay.co.uk> From: "Steven Hartland" To: "Jack Vogel" References: <379885BA631F4C7787C24E00A174B429@multiplay.co.uk> Date: Tue, 19 Jul 2011 00:09:54 +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 Cc: freebsd-net@freebsd.org, Kevin Oberman 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: Mon, 18 Jul 2011 23:10:57 -0000 ----- Original Message ----- From: "Jack Vogel" >I have no idea... but as a matter of principle I would see if updating to > later code, > both OS and especially the driver, reproduces the issue. Our validation > group often has Linux as a link partner in testing, which can be good and bad, > it actually sometimes has problems that FBSD on both sides doesn't. Confirmed tcp connections still stall with the target running the latest 8-STABLE as of today. dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 2.2.3 Really running out of ideas to even try here now :( 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 Tue Jul 19 05:17: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 54882106566B; Tue, 19 Jul 2011 05:17:01 +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 2BE498FC13; Tue, 19 Jul 2011 05:17: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 p6J5H1wn058709; Tue, 19 Jul 2011 05:17:01 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6J5H11A058705; Tue, 19 Jul 2011 05:17:01 GMT (envelope-from linimon) Date: Tue, 19 Jul 2011 05:17:01 GMT Message-Id: <201107190517.p6J5H11A058705@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/159019: [ip6] freebsd ipv6 address are advertised but do not respond X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jul 2011 05:17:01 -0000 Old Synopsis: freebsd ipv6 address are advertised but do not respond New Synopsis: [ip6] freebsd ipv6 address are advertised but do not respond Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Jul 19 05:16:38 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=159019 From owner-freebsd-net@FreeBSD.ORG Tue Jul 19 07:40:13 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D70581065670; Tue, 19 Jul 2011 07:40:13 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 2CCD48FC14; Tue, 19 Jul 2011 07:40:13 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1Qj4uZ-0005nH-SR; Tue, 19 Jul 2011 10:40:11 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Eygene Ryabinkin In-reply-to: <20110718203215.GM54929@MacBook-Eygene-Ryabinkin.local> References: <20110718203215.GM54929@MacBook-Eygene-Ryabinkin.local> Comments: In-reply-to Eygene Ryabinkin message dated "Tue, 19 Jul 2011 00:32:15 +0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Jul 2011 10:40:11 +0300 From: Daniel Braniss Message-ID: Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: broadcast oddity X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jul 2011 07:40:14 -0000 Hi Eygene, > Daniel, good day. > > Mon, Jul 18, 2011 at 05:04:27PM +0300, Daniel Braniss wrote: > > this code behaves correctly when run from a diskless host which > > booted via PXE, but fails on a host that was booted from disk. > > hint: the non working sends a packet with a non ethernet broadcast > > address and an ip address of 255.255.255.255, > > And that non-broadcast ethernet address is the MAC of your > default router? yes. > > > the working version sets the ethernet address to 0xffffffff and the > > ip to the network broadcast address. > > What's your routing table (netstat -rn) for the PXE-booted host? it's ok, same in both cases. it's picked up via DHCP, in the diskless case by the boot/loader in the second via dhcpclient. > > > what am I doing wrong? > >=20 > > danny > > PS: what is the correct way to obtain the network broadcast address? > > You nailed it: you should send packets to the network's broadcast, > not to the 0xffffffff. > but I'm at the user/ip level!, have no way to set mac/ethernet address. still, the question is why it works in one case, and failes in the other. > And in order to find the broadcast address for the interface (or > network at that interface), you should use getifaddrs(), like in the > attached example. It is very quick and dirty one and it has some > limitations (e.g., it takes the first broadcast address from the > interface), but it should be a good starting point. thanks, danny > Eygene Ryabinkin ,,,^..^,,, > [ Life's unfair - but root password helps! | codelabs.ru ] > [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] > > --UeXZ3FjlYZvuln/G > Content-Type: text/plain; charset=us-ascii > Content-Disposition: attachment; filename="bcast.c" > > #include > #include > #include > #include > #include > #include > #include > #include > #include > > void > bcast(in_addr_t addr) > { > int so, on; > char msg[BUFSIZ]; > struct timespec t2; > struct sockaddr_in soin; > > if((so = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0) { > perror("socket"); > exit(-1); > } > on = 1; > if(setsockopt(so, SOL_SOCKET, SO_BROADCAST, &on, sizeof(on))) { > perror("setsockopt"); > exit(-1); > } > > bzero(&soin, sizeof(struct sockaddr_in)); > soin.sin_len = sizeof(struct sockaddr_in); > soin.sin_family = AF_INET; > soin.sin_addr.s_addr = addr; > soin.sin_port = htons(12345); > while(1) { > clock_gettime(CLOCK_REALTIME, &t2); > sprintf(msg, "0x%016x", t2.tv_sec); > if(sendto(so, msg, strlen(msg)+1, > 0, (struct sockaddr *)&soin, sizeof(struct sockaddr)) < 0) { > perror("sendto"); > break; > } > sleep(10); > } > } > > main(int argc, char *argv[]) > { > struct ifaddrs *ifap, *ifa, *our_if; > struct sockaddr_in *sin; > > if (argc < 2) > errx(1, "No arguments"); > if (getifaddrs(&ifap) != 0) > perror("getifaddrs"); > our_if = NULL; > for (ifa = ifap; ifa != NULL; ifa = ifa->ifa_next) { > if (strcmp(argv[1], ifa->ifa_name) == 0) { > sin = (struct sockaddr_in *)ifa->ifa_broadaddr; > if (!(ifa->ifa_flags & IFF_BROADCAST) || > sin == NULL || > sin->sin_addr.s_addr == 0) > continue; > our_if = ifa; > break; > } > } > if (!our_if) > errx(1, "Can't find broadcast-able interface '%s'", argv[1]); > bcast(sin->sin_addr.s_addr); > freeifaddrs(ifap); > } > > --UeXZ3FjlYZvuln/G-- > > --McpcKDxJRrEJVmOH > Content-Type: application/pgp-signature > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (Darwin) > > iF0EAREIAAYFAk4kmE8ACgkQFq+eroFS7PvE+QD/ZL0cpFaKvLA+ZWWFH/QlA5Xb > hqKEG+XY90zdya2/twEA9R3xcK8wwRtOiLf7Tb9SHviukeMsrxwufSWhdapJfj0= > =Iujs > -----END PGP SIGNATURE----- > > --McpcKDxJRrEJVmOH-- From owner-freebsd-net@FreeBSD.ORG Tue Jul 19 07:46:50 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 C2BAD106566B; Tue, 19 Jul 2011 07:46:50 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9A8A18FC18; Tue, 19 Jul 2011 07:46:50 +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 p6J7koB3020993; Tue, 19 Jul 2011 07:46:50 GMT (envelope-from dougb@freefall.freebsd.org) Received: (from dougb@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6J7koK4020989; Tue, 19 Jul 2011 07:46:50 GMT (envelope-from dougb) Date: Tue, 19 Jul 2011 07:46:50 GMT Message-Id: <201107190746.p6J7koK4020989@freefall.freebsd.org> To: cattelan@thebarn.com, dougb@FreeBSD.org, freebsd-net@FreeBSD.org, dougb@FreeBSD.org From: dougb@FreeBSD.org Cc: Subject: Re: kern/159019: [ip6] freebsd ipv6 address are advertised but do not respond X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jul 2011 07:46:50 -0000 Synopsis: [ip6] freebsd ipv6 address are advertised but do not respond State-Changed-From-To: open->closed State-Changed-By: dougb State-Changed-When: Tue Jul 19 07:45:13 UTC 2011 State-Changed-Why: That address is responding over IPv6 for me, you might have a local connectivity issue, or we had a temporary outage. If it happens again, confirm that you can reach other IPv6 sites first, and if so send mail to hostmaster@FreeBSD.org. Responsible-Changed-From-To: freebsd-net->dougb Responsible-Changed-By: dougb Responsible-Changed-When: Tue Jul 19 07:45:13 UTC 2011 Responsible-Changed-Why: I closed it http://www.freebsd.org/cgi/query-pr.cgi?pr=159019 From owner-freebsd-net@FreeBSD.ORG Tue Jul 19 11:16: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 4978A106564A for ; Tue, 19 Jul 2011 11:16:28 +0000 (UTC) (envelope-from prvs=1181b50c55=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 C12248FC19 for ; Tue, 19 Jul 2011 11:16:27 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Tue, 19 Jul 2011 12:05:03 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 19 Jul 2011 12:04:57 +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 md50014221054.msg for ; Tue, 19 Jul 2011 12:04:56 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1181b50c55=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <00F86D895BEA493E8FB82F0CDF42AA04@multiplay.co.uk> From: "Steven Hartland" To: "Jack Vogel" References: <379885BA631F4C7787C24E00A174B429@multiplay.co.uk> Date: Tue, 19 Jul 2011 12:05:12 +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 Cc: freebsd-net@freebsd.org, Kevin Oberman 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: Tue, 19 Jul 2011 11:16:28 -0000 Ok making some progress now, disabling msix by setting hw.igb.enable_msix=0 in /boot/loader.conf fixes the stalls, so I'm guessing this indicates a driver issue? My current test case is a repeating scp of the freebsd iso from 3 local machines + 1 remote to the target machine, which seems to be enough to reproduce the stall within ~30mins if its going to happen. I also tried setting hw.igb.num_queues=1 with msix enabled but I was still able to create a stall with this config. Is there some debugging I can do to help track this down? 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 Tue Jul 19 17:25:00 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 927571065675; Tue, 19 Jul 2011 17:25:00 +0000 (UTC) (envelope-from rea@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 3B4A48FC0A; Tue, 19 Jul 2011 17:24:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codelabs.ru; s=two; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=r4BBFeN+uFRA8/dKCD4KHhhRNaIYiRCRqNA7BEYVp4c=; b=p5ScyJreiVXk5U7jZuoQAi1MgcEfoqAmOGvnDtBg2Jn7y+EktWbFcckbLe2pXUJ4fnBXqyIXaQvVfMNMEBB15tleqnQg6n5wbQ523Tb63No2BZ8/2hALr9+6/KEYAh2Q1x4/bqiUX9PtDZB1v5WnVy/Q1+zlnrIsb95wU9x5f4/ZXlQwWXi0Thi/P9smmaBYLXMnhRRvWkpvfjjdSEJU/MIz/NeBR4pLnVzI98ELowRiXRacsIrTxqH1LvxkmKU7EGNT/3VXjOUFjdH01UJYlOkacCLcXff5C1QnrSno0ZPpJ9DzkGBvfNhrJIQye8EGLeVCnPLOvVt7QaLP2K7oWg==; Received: from MacBook-Eygene-Ryabinkin.local (ppp91-77-162-156.pppoe.mtu-net.ru [91.77.162.156]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1QjE2U-000OfO-PD; Tue, 19 Jul 2011 21:24:58 +0400 Date: Tue, 19 Jul 2011 21:24:55 +0400 From: Eygene Ryabinkin To: Daniel Braniss Message-ID: <20110719172455.GP54929@MacBook-Eygene-Ryabinkin.local> References: <20110718203215.GM54929@MacBook-Eygene-Ryabinkin.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NEaRsfQExFH3jWtg" Content-Disposition: inline In-Reply-To: Sender: rea@codelabs.ru Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: broadcast oddity X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jul 2011 17:25:00 -0000 --NEaRsfQExFH3jWtg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Tue, Jul 19, 2011 at 10:40:11AM +0300, Daniel Braniss wrote: > > And that non-broadcast ethernet address is the MAC of your > > default router? > yes. Fine, that is more-or-less expected, since the network subsystem just routes 255.255.255.255 to the default gateway. The issue you're seeing were already seen before, http://lists.freebsd.org/pipermail/freebsd-net/2005-October/008626.html http://www.freebsd.org/cgi/query-pr.cgi?pr=3D72468 http://lists.freebsd.org/pipermail/freebsd-net/2007-January/012874.html [= 1] and bms@ told me that in this case the default gateway routing is the correct historical behaviour of FreeBSD. [1] I finally remembered that I had seen this issue too ;)) > > What's your routing table (netstat -rn) for the PXE-booted host? > > it's ok, same in both cases. it's picked up via DHCP, in the diskless > case by the boot/loader in the second via dhcpclient. Still, can you show both of them? > > You nailed it: you should send packets to the network's broadcast, > > not to the 0xffffffff. > >=20 > but I'm at the user/ip level!, have no way to set mac/ethernet address. I meant the IP's network broadcast and by 0xffffffff I meant 255.255.255.255. Please, look at the posted code. > still, the question is why it works in one case, and failes in the other. Yes, it is. But ip_output.c has the following code, {{{ if (rte->rt_flags & RTF_GATEWAY) dst =3D (struct sockaddr_in *)rte->rt_gateway; if (rte->rt_flags & RTF_HOST) isbroadcast =3D (rte->rt_flags & RTF_BROADCAST); else isbroadcast =3D in_broadcast(dst->sin_addr, ifp); }}} So, if the route that is selected is the gateway, then there will be no broadcast on the L2. At least in my understanding of the code. Thus, I am interested in the routing tables and route flags. --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --NEaRsfQExFH3jWtg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iF4EAREIAAYFAk4lvecACgkQFq+eroFS7PtqOwEAkdzoSVbsOv1x01hTfYMQHmN5 sooNn8einiX32BR/PSEA/iJAOVvMn38joKNp8hCxLFUuzm34zc1XLGMSrlnh0B8U =zEhc -----END PGP SIGNATURE----- --NEaRsfQExFH3jWtg-- From owner-freebsd-net@FreeBSD.ORG Wed Jul 20 09:34:41 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 837C2106566C; Wed, 20 Jul 2011 09:34:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id DB6F18FC13; Wed, 20 Jul 2011 09:34:40 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1QjTAs-000IjW-Ba; Wed, 20 Jul 2011 12:34:38 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Eygene Ryabinkin In-reply-to: <20110719172455.GP54929@MacBook-Eygene-Ryabinkin.local> References: <20110718203215.GM54929@MacBook-Eygene-Ryabinkin.local> <20110719172455.GP54929@MacBook-Eygene-Ryabinkin.local> Comments: In-reply-to Eygene Ryabinkin message dated "Tue, 19 Jul 2011 21:24:55 +0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Jul 2011 12:34:38 +0300 From: Daniel Braniss Message-ID: Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: broadcast oddity X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jul 2011 09:34:41 -0000 > Tue, Jul 19, 2011 at 10:40:11AM +0300, Daniel Braniss wrote: > > > And that non-broadcast ethernet address is the MAC of your > > > default router? > > yes. with dest_addr = INADDR_BROADCAST on the non diskless: 09:44:29.850576 00:0d:b9:00:72:a8 (oui Unknown) > 00:04:38:a0:c6:07 (oui Unknown), ethertype IPv4 (0x0800), length 61: wrap-1.cs.huji.ac.il.53016 > 255.255.255.255.12345: UDP, length 19 and 00:04:38:a0:c6:07 belongs to the router: wrap-1# arp -a | grep 00:04:38:a0:c6:07 router-80.cs.huji.ac.il (132.65.80.1) at 00:04:38:a0:c6:07 on sis0 expires in 1200 seconds [ethernet] > > Fine, that is more-or-less expected, since the network subsystem > just routes 255.255.255.255 to the default gateway. The issue > you're seeing were already seen before, > http://lists.freebsd.org/pipermail/freebsd-net/2005-October/008626.html > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D72468 > http://lists.freebsd.org/pipermail/freebsd-net/2007-January/012874.html [= > 1] the more I read the more confused i get :-) > and bms@ told me that in this case the default gateway routing is the > correct historical behaviour of FreeBSD. > > [1] I finally remembered that I had seen this issue too ;)) > > > > What's your routing table (netstat -rn) for the PXE-booted host? > > > > it's ok, same in both cases. it's picked up via DHCP, in the diskless > > case by the boot/loader in the second via dhcpclient. > > Still, can you show both of them? from the diskless: els-01# ifconfig vr0: flags=8843 metric 0 mtu 1500 options=8280b ether 00:0d:b9:22:57:18 inet 132.65.91.1 netmask 0xfffff000 broadcast 132.65.95.255 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 els-01# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 132.65.80.1 UG 0 16606 vr0 127.0.0.1 link#4 UH 0 36 lo0 132.65.80.0/20 link#1 U 0 86612 vr0 132.65.91.1 link#1 UHS 0 12 lo0 from the non-diskless: wrap-1# ifconfig sis0: flags=8943 metric 0 mtu 1500 options=83808 ether 00:0d:b9:00:72:a8 inet 132.65.80.181 netmask 0xfffff000 broadcast 132.65.95.255 media: Ethernet autoselect (100baseTX ) status: active sis1: flags=8802 metric 0 mtu 1500 options=83808 ether 00:0d:b9:00:72:a9 media: Ethernet autoselect (none) status: no carrier lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 wrap-1# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 132.65.80.1 UGS 0 16936 sis0 127.0.0.1 link#4 UH 0 76 lo0 132.65.80.0/20 link#1 U 0 67433 sis0 132.65.80.181 link#1 UHS 0 0 lo0 > > > > You nailed it: you should send packets to the network's broadcast, > > > not to the 0xffffffff. > > >=20 > > but I'm at the user/ip level!, have no way to set mac/ethernet address. > > I meant the IP's network broadcast and by 0xffffffff I meant > 255.255.255.255. Please, look at the posted code. > > > still, the question is why it works in one case, and failes in the other. > > Yes, it is. But ip_output.c has the following code, > {{{ > if (rte->rt_flags & RTF_GATEWAY) > dst =3D (struct sockaddr_in *)rte->rt_gateway; > if (rte->rt_flags & RTF_HOST) > isbroadcast =3D (rte->rt_flags & RTF_BROADCAST); > else > isbroadcast =3D in_broadcast(dst->sin_addr, ifp); > }}} > > So, if the route that is selected is the gateway, then there will be > no broadcast on the L2. At least in my understanding of the code. > Thus, I am interested in the routing tables and route flags. so it boils down to a problem in selecting the route? cheers, danny From owner-freebsd-net@FreeBSD.ORG Wed Jul 20 14:39: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 1458C1065670 for ; Wed, 20 Jul 2011 14:39:03 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id C78028FC18 for ; Wed, 20 Jul 2011 14:39:02 +0000 (UTC) Received: from mr12941.univ-rennes1.fr (mr129041.cri.univ-rennes1.fr [129.20.129.41]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 49D1163307B; Wed, 20 Jul 2011 16:19:25 +0200 (CEST) Received: from mr12941 (localhost.localdomain [127.0.0.1]) by mr12941.univ-rennes1.fr (Postfix) with ESMTP id B815D7A0108; Wed, 20 Jul 2011 16:19:24 +0200 (CEST) Date: Wed, 20 Jul 2011 16:19:24 +0200 From: Patrick Lamaiziere To: "Kim A. Brandt" Message-ID: <20110720161924.26a4fcf0@mr12941> In-Reply-To: <4E244EDD.2000709@peterhost.ru> References: <4E243D8F.1020305@gmx.de> <4E244EDD.2000709@peterhost.ru> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.24.4; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: CARP-interface fail-over in case required program fails. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jul 2011 14:39:03 -0000 Le Mon, 18 Jul 2011 19:18:53 +0400, Dmitry Banschikov a écrit : Hi, > > is it possible to let a CARP-interface fail(-over) in the situation > > when a certain program fails or stops working? I hope it's clear > > enough what I have in mind. Could you give me any pointers on how > > this can be archived? > > You can write simple script, which will monitor status of the > program, and if program fails, it can adjust advskew parameter of the > CARP interface forcing going interface to the backup state. In addition, port net/ifstated could be useful for doing this kind of things (here we monitor BGP sessions with it). From owner-freebsd-net@FreeBSD.ORG Wed Jul 20 15:37: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 C4E6F106566C for ; Wed, 20 Jul 2011 15:37:01 +0000 (UTC) (envelope-from kimabrandt@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by mx1.freebsd.org (Postfix) with SMTP id 496498FC08 for ; Wed, 20 Jul 2011 15:37:01 +0000 (UTC) Received: (qmail invoked by alias); 20 Jul 2011 15:36:59 -0000 Received: from x1-6-c4-3d-c7-27-b9-1a.k6.webspeed.dk (EHLO [172.16.0.110]) [80.63.18.226] by mail.gmx.net (mp070) with SMTP; 20 Jul 2011 17:36:59 +0200 X-Authenticated: #32880209 X-Provags-ID: V01U2FsdGVkX1965FMX9vx6MCKRXMP9FAxdt9m6KKvd+dn4zDCfd8 zdBrEXUzPivcpD Message-ID: <4E26F617.1030405@gmx.de> Date: Wed, 20 Jul 2011 17:36:55 +0200 From: "Kim A. Brandt" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Patrick Lamaiziere References: <4E243D8F.1020305@gmx.de> <4E244EDD.2000709@peterhost.ru> <20110720161924.26a4fcf0@mr12941> In-Reply-To: <20110720161924.26a4fcf0@mr12941> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060608060902060801030209" X-Y-GMX-Trusted: 0 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: CARP-interface fail-over in case required program fails. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jul 2011 15:37:01 -0000 This is a cryptographically signed message in MIME format. --------------ms060608060902060801030209 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Patrick and Dmitry, indeed `ifstated' and the ``running external tests''-part, sound like it = will be helpful. /Kim On 2011-07-20 16:19, Patrick Lamaiziere wrote: > Le Mon, 18 Jul 2011 19:18:53 +0400, > Dmitry Banschikov a =C3=A9crit : >=20 > Hi, >=20 >>> is it possible to let a CARP-interface fail(-over) in the situation >>> when a certain program fails or stops working? I hope it's clear >>> enough what I have in mind. Could you give me any pointers on how >>> this can be archived? >> >> You can write simple script, which will monitor status of the >> program, and if program fails, it can adjust advskew parameter of the >> CARP interface forcing going interface to the backup state. >=20 > In addition, port net/ifstated could be useful for doing this kind of > things (here we monitor BGP sessions with it). --------------ms060608060902060801030209-- From owner-freebsd-net@FreeBSD.ORG Wed Jul 20 15:50:10 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46086106566B for ; Wed, 20 Jul 2011 15:50:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3571F8FC14 for ; Wed, 20 Jul 2011 15:50:10 +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 p6KFo96l032570 for ; Wed, 20 Jul 2011 15:50:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6KFo9rH032569; Wed, 20 Jul 2011 15:50:09 GMT (envelope-from gnats) Date: Wed, 20 Jul 2011 15:50:09 GMT Message-Id: <201107201550.p6KFo9rH032569@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Michael W. Lucas" Cc: Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Michael W. Lucas" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 15:50:10 -0000 The following reply was made to PR kern/152828; it has been noted by GNATS. From: "Michael W. Lucas" To: bug-followup@FreeBSD.org Cc: rick@sloservers.com Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE Date: Wed, 20 Jul 2011 11:49:08 -0400 I'm seeing the exact same problem here as the original poster. Is anybody looking at this? Running FreeBSD 8.2-RELEASE-p1 amd64, from FreeNAS 8.0 sysctls: dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.1.9 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x108b subvendor=0x8086 subdevice=0x0000 class=0x020000 dev.em.0.%parent: pci1 dev.em.0.nvm: -1 dev.em.0.debug: -1 ... ifconfig: em0: flags=8843 metric 0 mtu 1500 options=219b ether 00:15:17:31:c8:fe inet 139.171.199.13 netmask 0xffffff00 broadcast 139.171.199.255 media: Ethernet autoselect (1000baseT ) status: active dmesg | grep em0 em0: port 0xbc00-0xbc1f mem 0xff6e0000-0xff6fffff irq 16 at device 0.0 on pci1 em0: Using an MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:31:c8:fe -- Michael W. Lucas http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ Latest book: Network Flow Analysis http://www.networkflowanalysis.com/ mwlucas@BlackHelicopters.org, Twitter @mwlauthor From owner-freebsd-net@FreeBSD.ORG Wed Jul 20 16:19:20 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6602D1065677 for ; Wed, 20 Jul 2011 16:19:20 +0000 (UTC) (envelope-from prvs=1182c8178b=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 AFAFB8FC18 for ; Wed, 20 Jul 2011 16:19:19 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Wed, 20 Jul 2011 17:07:30 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 20 Jul 2011 17:07:30 +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 md50014237766.msg for ; Wed, 20 Jul 2011 17:07:29 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1182c8178b=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@FreeBSD.org Message-ID: <54AEE240C5F8411A9D4274605DBD14BC@multiplay.co.uk> From: "Steven Hartland" To: "Michael W. Lucas" , References: <201107201550.p6KFo9rH032569@freefall.freebsd.org> Date: Wed, 20 Jul 2011 17:07:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; 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 Cc: Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jul 2011 16:19:20 -0000 We're seeing tcp stalls under igb under 8.2-RELEASE and 8-STABLE (which shares some code with em) and the workaround for use is currently adding the following to /boot/loader.conf hw.igb.enable_msix=0 Might be worth trying that. Regards Steve ----- Original Message ----- From: "Michael W. Lucas" To: Sent: Wednesday, July 20, 2011 4:50 PM Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE > The following reply was made to PR kern/152828; it has been noted by GNATS. > > From: "Michael W. Lucas" > To: bug-followup@FreeBSD.org > Cc: rick@sloservers.com > Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE > Date: Wed, 20 Jul 2011 11:49:08 -0400 > > I'm seeing the exact same problem here as the original poster. Is > anybody looking at this? > > Running FreeBSD 8.2-RELEASE-p1 amd64, from FreeNAS 8.0 > > sysctls: > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.1.9 > dev.em.0.%driver: em > dev.em.0.%location: slot=0 function=0 > dev.em.0.%pnpinfo: vendor=0x8086 device=0x108b subvendor=0x8086 subdevice=0x0000 class=0x020000 > dev.em.0.%parent: pci1 > dev.em.0.nvm: -1 > dev.em.0.debug: -1 > ... > > ifconfig: > em0: flags=8843 metric 0 mtu 1500 > options=219b > ether 00:15:17:31:c8:fe > inet 139.171.199.13 netmask 0xffffff00 broadcast 139.171.199.255 > media: Ethernet autoselect (1000baseT ) > status: active > > dmesg | grep em0 > em0: port 0xbc00-0xbc1f mem 0xff6e0000-0xff6fffff irq 16 at device 0.0 on pci1 > em0: Using an MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:15:17:31:c8:fe > > > > > -- > Michael W. Lucas > http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ > Latest book: Network Flow Analysis http://www.networkflowanalysis.com/ > mwlucas@BlackHelicopters.org, Twitter @mwlauthor > _______________________________________________ > 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" > ================================================ 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 Wed Jul 20 16:38: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 612561065735 for ; Wed, 20 Jul 2011 16:38:54 +0000 (UTC) (envelope-from jfvogel@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 710938FC08 for ; Wed, 20 Jul 2011 16:38:54 +0000 (UTC) Received: by vws18 with SMTP id 18so413749vws.13 for ; Wed, 20 Jul 2011 09:38:53 -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=rjfhCg4ETN2O55UiuVBlI3Gk5T3Banfq+TYWNm6+P78=; b=fJHKyBxD7vYP58560fid+hPEYReyngZ9GWgTZGvQ17geenWDTnZ2QWnQabubx9dcBl lQ2f7L5Ve3F+chpkrfAF0z6iB/cgTbggW5/HNkbLo6CRIQ5gGp/umiUrCOe4uwZg2xNz LeFRwkePBZz78Gewd1VahK42XaXH0EQGj08ao= MIME-Version: 1.0 Received: by 10.52.69.39 with SMTP id b7mr639815vdu.264.1311179933339; Wed, 20 Jul 2011 09:38:53 -0700 (PDT) Received: by 10.52.187.66 with HTTP; Wed, 20 Jul 2011 09:38:53 -0700 (PDT) In-Reply-To: <54AEE240C5F8411A9D4274605DBD14BC@multiplay.co.uk> References: <201107201550.p6KFo9rH032569@freefall.freebsd.org> <54AEE240C5F8411A9D4274605DBD14BC@multiplay.co.uk> Date: Wed, 20 Jul 2011 09:38:53 -0700 Message-ID: From: Jack Vogel 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, "Michael W. Lucas" Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jul 2011 16:38:55 -0000 This is an em bug, igb does not share interrupt code with em, furthermore the adapter the filer of the bug is using doesn't use MSIX, only one type in the em driver does, and I might add lots of heavy users on that adapter have MSIX on without issues. I believe turning MSIX off is just masking whatever your real issue is, if you wish to run that way that's fine, but please don't advertise that as a 'fix' in some general way. Regards, Jack On Wed, Jul 20, 2011 at 9:07 AM, Steven Hartland wrote: > We're seeing tcp stalls under igb under 8.2-RELEASE and 8-STABLE (which > shares > some code with em) and the workaround for use is currently adding the > following > to /boot/loader.conf > hw.igb.enable_msix=0 > > Might be worth trying that. > > Regards > Steve > > ----- Original Message ----- From: "Michael W. Lucas" < > mwlucas@blackhelicopters.org> > To: > Sent: Wednesday, July 20, 2011 4:50 PM > > Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE > > > The following reply was made to PR kern/152828; it has been noted by >> GNATS. >> >> From: "Michael W. Lucas" >> To: bug-followup@FreeBSD.org >> Cc: rick@sloservers.com >> Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE >> Date: Wed, 20 Jul 2011 11:49:08 -0400 >> >> I'm seeing the exact same problem here as the original poster. Is >> anybody looking at this? >> >> Running FreeBSD 8.2-RELEASE-p1 amd64, from FreeNAS 8.0 >> >> sysctls: >> dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.1.9 >> dev.em.0.%driver: em >> dev.em.0.%location: slot=0 function=0 >> dev.em.0.%pnpinfo: vendor=0x8086 device=0x108b subvendor=0x8086 >> subdevice=0x0000 class=0x020000 >> dev.em.0.%parent: pci1 >> dev.em.0.nvm: -1 >> dev.em.0.debug: -1 >> ... >> >> ifconfig: >> em0: flags=8843 metric 0 mtu >> 1500 >> options=219b> HWCSUM,TSO4,WOL_MAGIC> >> ether 00:15:17:31:c8:fe >> inet 139.171.199.13 netmask 0xffffff00 broadcast 139.171.199.255 >> media: Ethernet autoselect (1000baseT ) >> status: active >> >> dmesg | grep em0 >> em0: port 0xbc00-0xbc1f mem >> 0xff6e0000-0xff6fffff irq 16 at device 0.0 on pci1 >> em0: Using an MSI interrupt >> em0: [FILTER] >> em0: Ethernet address: 00:15:17:31:c8:fe >> >> >> >> >> -- >> Michael W. Lucas http://www.MichaelWLucas.com/, >> http://blather.MichaelWLucas.**com/ >> Latest book: Network Flow Analysis http://www.**networkflowanalysis.com/ >> mwlucas@BlackHelicopters.org, Twitter @mwlauthor >> ______________________________**_________________ >> 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 >> " >> >> > ==============================**================== > 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. > > > ______________________________**_________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@**freebsd.org > " > From owner-freebsd-net@FreeBSD.ORG Wed Jul 20 17:02: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 248A41065672 for ; Wed, 20 Jul 2011 17:02:24 +0000 (UTC) (envelope-from prvs=1182c8178b=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 3D80A8FC12 for ; Wed, 20 Jul 2011 17:02:22 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Wed, 20 Jul 2011 18:01:50 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 20 Jul 2011 18:01: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 md50014238502.msg for ; Wed, 20 Jul 2011 18:01:49 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1182c8178b=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <2976D84B193E4D7DAE6F4C4E28B8F909@multiplay.co.uk> From: "Steven Hartland" To: "Jack Vogel" References: <201107201550.p6KFo9rH032569@freefall.freebsd.org><54AEE240C5F8411A9D4274605DBD14BC@multiplay.co.uk> Date: Wed, 20 Jul 2011 18:02:12 +0100 MIME-Version: 1.0 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 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, "Michael W. Lucas" Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jul 2011 17:02:24 -0000 Apologies, thought it might be worth a shot, but clearly not thanks for clarifying :) You absolutely correct with the msix masking the issue, we've just this minute had it stall again even with MSIX disabled :( I agree we have many machines using igb and em without issue even under lots of load. Not wishing to hijack this thread, but any advise on what else to try to diagnose this stalling issue would be gratefully received. Regards Steve ----- Original Message -----=20 From: Jack Vogel=20 To: Steven Hartland=20 Cc: Michael W. Lucas ; freebsd-net@freebsd.org=20 Sent: Wednesday, July 20, 2011 5:38 PM Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE This is an em bug, igb does not share interrupt code with em, furthermore the adapter the filer of the bug is using doesn't use MSIX, only one type in the em driver does, and I might add lots of heavy users on that adapter have MSIX on without issues. I believe turning MSIX off is just masking whatever your real issue is, if you wish to run that way that's fine, but please don't advertise that as a 'fix' in some general way. Regards, Jack On Wed, Jul 20, 2011 at 9:07 AM, Steven Hartland wrote: We're seeing tcp stalls under igb under 8.2-RELEASE and 8-STABLE (which shares some code with em) and the workaround for use is currently adding the following to /boot/loader.conf hw.igb.enable_msix=3D0 Might be worth trying that. Regards Steve ----- Original Message ----- From: "Michael W. Lucas" To: Sent: Wednesday, July 20, 2011 4:50 PM Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE The following reply was made to PR kern/152828; it has been noted by GNATS. From: "Michael W. Lucas" To: bug-followup@FreeBSD.org Cc: rick@sloservers.com Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE Date: Wed, 20 Jul 2011 11:49:08 -0400 I'm seeing the exact same problem here as the original poster. Is anybody looking at this? Running FreeBSD 8.2-RELEASE-p1 amd64, from FreeNAS 8.0 sysctls: dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.1.9 dev.em.0.%driver: em dev.em.0.%location: slot=3D0 function=3D0 dev.em.0.%pnpinfo: vendor=3D0x8086 device=3D0x108b subvendor=3D0x8086 subdevice=3D0x0000 class=3D0x020000 dev.em.0.%parent: pci1 dev.em.0.nvm: -1 dev.em.0.debug: -1 ... ifconfig: em0: flags=3D8843 metric 0 mtu 1500 options=3D219b ether 00:15:17:31:c8:fe inet 139.171.199.13 netmask 0xffffff00 broadcast 139.171.199.255 media: Ethernet autoselect (1000baseT ) status: active dmesg | grep em0 em0: port 0xbc00-0xbc1f mem 0xff6e0000-0xff6fffff irq 16 at device 0.0 on pci1 em0: Using an MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:31:c8:fe --=20 Michael W. Lucas http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ Latest book: Network Flow Analysis http://www.networkflowanalysis.com/ mwlucas@BlackHelicopters.org, Twitter @mwlauthor _______________________________________________ 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" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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.=20 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. _______________________________________________ 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" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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.=20 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 Wed Jul 20 17:03:49 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0921F1065670 for ; Wed, 20 Jul 2011 17:03:49 +0000 (UTC) (envelope-from jfvogel@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 B77CB8FC12 for ; Wed, 20 Jul 2011 17:03:48 +0000 (UTC) Received: by vws18 with SMTP id 18so438768vws.13 for ; Wed, 20 Jul 2011 10:03:48 -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=LCwwCGJI4EeRJTyU5+zGoDbNCMMuU61Uy4xvMUnFllQ=; b=BCOLganPimGodWvseNLaLBDjjgLCPdxa4HYa8wKbbqP+Y7irQhGLj/QMxHqboCEl8/ BjtMuE/25b6hD03qEzET18er0rba7nujs8qPGl0RBBqktbfAZ+74JnxWSkCRev6jK1Zn DQ4qBAIo9O1us76a8niR4+vlKB7wmpMihujRs= MIME-Version: 1.0 Received: by 10.52.21.243 with SMTP id y19mr9103496vde.178.1311181427737; Wed, 20 Jul 2011 10:03:47 -0700 (PDT) Received: by 10.52.187.66 with HTTP; Wed, 20 Jul 2011 10:03:47 -0700 (PDT) In-Reply-To: <2976D84B193E4D7DAE6F4C4E28B8F909@multiplay.co.uk> References: <201107201550.p6KFo9rH032569@freefall.freebsd.org> <54AEE240C5F8411A9D4274605DBD14BC@multiplay.co.uk> <2976D84B193E4D7DAE6F4C4E28B8F909@multiplay.co.uk> Date: Wed, 20 Jul 2011 10:03:47 -0700 Message-ID: From: Jack Vogel 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, "Michael W. Lucas" Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jul 2011 17:03:49 -0000 Did you eliminate that 7.0 box as part of the issue? Meaning switch to say a Linux or 8.2 partner to see if the problem persists or stops? Cheers, Jack On Wed, Jul 20, 2011 at 10:02 AM, Steven Hartland wrote: > ** > Apologies, thought it might be worth a shot, but clearly not thanks for > clarifying :) > > You absolutely correct with the msix masking the issue, we've just this > minute had it stall again even with MSIX disabled :( > > I agree we have many machines using igb and em without issue even under > lots of load. > > Not wishing to hijack this thread, but any advise on what else to try to > diagnose this stalling issue would be gratefully received. > > Regards > Steve > > ----- Original Message ----- > *From:* Jack Vogel > *To:* Steven Hartland > *Cc:* Michael W. Lucas ; > freebsd-net@freebsd.org > *Sent:* Wednesday, July 20, 2011 5:38 PM > *Subject:* Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE > > This is an em bug, igb does not share interrupt code with em, furthermore > the adapter > the filer of the bug is using doesn't use MSIX, only one type in the em > driver does, > and I might add lots of heavy users on that adapter have MSIX on without > issues. > > I believe turning MSIX off is just masking whatever your real issue is, if > you wish to > run that way that's fine, but please don't advertise that as a 'fix' in > some general way. > > Regards, > > Jack > > > On Wed, Jul 20, 2011 at 9:07 AM, Steven Hartland wrote: > >> We're seeing tcp stalls under igb under 8.2-RELEASE and 8-STABLE (which >> shares >> some code with em) and the workaround for use is currently adding the >> following >> to /boot/loader.conf >> hw.igb.enable_msix=0 >> >> Might be worth trying that. >> >> Regards >> Steve >> >> ----- Original Message ----- From: "Michael W. Lucas" < >> mwlucas@blackhelicopters.org> >> To: >> Sent: Wednesday, July 20, 2011 4:50 PM >> >> Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE >> >> >> The following reply was made to PR kern/152828; it has been noted by >>> GNATS. >>> >>> From: "Michael W. Lucas" >>> To: bug-followup@FreeBSD.org >>> Cc: rick@sloservers.com >>> Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE >>> Date: Wed, 20 Jul 2011 11:49:08 -0400 >>> >>> I'm seeing the exact same problem here as the original poster. Is >>> anybody looking at this? >>> >>> Running FreeBSD 8.2-RELEASE-p1 amd64, from FreeNAS 8.0 >>> >>> sysctls: >>> dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.1.9 >>> dev.em.0.%driver: em >>> dev.em.0.%location: slot=0 function=0 >>> dev.em.0.%pnpinfo: vendor=0x8086 device=0x108b subvendor=0x8086 >>> subdevice=0x0000 class=0x020000 >>> dev.em.0.%parent: pci1 >>> dev.em.0.nvm: -1 >>> dev.em.0.debug: -1 >>> ... >>> >>> ifconfig: >>> em0: flags=8843 metric 0 mtu >>> 1500 >>> options=219b>> HWCSUM,TSO4,WOL_MAGIC> >>> ether 00:15:17:31:c8:fe >>> inet 139.171.199.13 netmask 0xffffff00 broadcast 139.171.199.255 >>> media: Ethernet autoselect (1000baseT ) >>> status: active >>> >>> dmesg | grep em0 >>> em0: port 0xbc00-0xbc1f mem >>> 0xff6e0000-0xff6fffff irq 16 at device 0.0 on pci1 >>> em0: Using an MSI interrupt >>> em0: [FILTER] >>> em0: Ethernet address: 00:15:17:31:c8:fe >>> >>> >>> >>> >>> -- >>> Michael W. Lucas http://www.MichaelWLucas.com/, >>> http://blather.MichaelWLucas.**com/ >>> Latest book: Network Flow Analysis http://www.**networkflowanalysis.com/ >>> mwlucas@BlackHelicopters.org, Twitter @mwlauthor >>> ______________________________**_________________ >>> 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 >>> " >>> >>> >> ==============================**================== >> 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 <%2B44%20845%20868%201337> >> or return the E.mail to postmaster@multiplay.co.uk. >> >> >> ______________________________**_________________ >> 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 >> " >> > > > ================================================ > 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 Wed Jul 20 17:15: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 9D7271065670 for ; Wed, 20 Jul 2011 17:15:25 +0000 (UTC) (envelope-from prvs=1182c8178b=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 128B68FC13 for ; Wed, 20 Jul 2011 17:15:24 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Wed, 20 Jul 2011 18:14:43 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 20 Jul 2011 18:14:37 +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 md50014238629.msg for ; Wed, 20 Jul 2011 18:14:30 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1182c8178b=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <4AED69DE7A474E49BA44470E898ADEDF@multiplay.co.uk> From: "Steven Hartland" To: "Jack Vogel" References: <201107201550.p6KFo9rH032569@freefall.freebsd.org><54AEE240C5F8411A9D4274605DBD14BC@multiplay.co.uk><2976D84B193E4D7DAE6F4C4E28B8F909@multiplay.co.uk> Date: Wed, 20 Jul 2011 18:13:34 +0100 MIME-Version: 1.0 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 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, "Michael W. Lucas" Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jul 2011 17:15:25 -0000 Yep, it stalls 8.2 partners as well :( ----- Original Message -----=20 From: Jack Vogel=20 To: Steven Hartland=20 Cc: Michael W. Lucas ; freebsd-net@freebsd.org=20 Sent: Wednesday, July 20, 2011 6:03 PM Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE Did you eliminate that 7.0 box as part of the issue? Meaning switch to say a Linux or 8.2 partner to see if the problem persists or stops? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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.=20 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 Wed Jul 20 17:18:34 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37EB91065670 for ; Wed, 20 Jul 2011 17:18:34 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9FD268FC17 for ; Wed, 20 Jul 2011 17:18:33 +0000 (UTC) Received: by vxg33 with SMTP id 33so452132vxg.13 for ; Wed, 20 Jul 2011 10:18:32 -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=EStC1lczoq256lu89Xw6DcZQaaQr7fsl0Oobs3pXBLs=; b=PdoYsJKC6wgOF9t9SrfojF1Rj9kaBpd8Oan3YmoqDMrj6fvUd6V7ci4h8KNXx4664I aKfTEQeE3aGKgw13dk+TBcgNzVDJ3c9Y6ZHOfKTSh22QbvZ224See/FZvGAzUE5ZlAKx Zo1IaHw/luoih49LwYjiXutuxhmqEwmM1Wp38= MIME-Version: 1.0 Received: by 10.52.22.201 with SMTP id g9mr6084336vdf.331.1311182312824; Wed, 20 Jul 2011 10:18:32 -0700 (PDT) Received: by 10.52.187.66 with HTTP; Wed, 20 Jul 2011 10:18:32 -0700 (PDT) In-Reply-To: <4AED69DE7A474E49BA44470E898ADEDF@multiplay.co.uk> References: <201107201550.p6KFo9rH032569@freefall.freebsd.org> <54AEE240C5F8411A9D4274605DBD14BC@multiplay.co.uk> <2976D84B193E4D7DAE6F4C4E28B8F909@multiplay.co.uk> <4AED69DE7A474E49BA44470E898ADEDF@multiplay.co.uk> Date: Wed, 20 Jul 2011 10:18:32 -0700 Message-ID: From: Jack Vogel 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, "Michael W. Lucas" Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jul 2011 17:18:34 -0000 Can you formulate a scenario that anyone else can setup and reproduce this? Jack On Wed, Jul 20, 2011 at 10:13 AM, Steven Hartland wrote: > ** > Yep, it stalls 8.2 partners as well :( > > ----- Original Message ----- > *From:* Jack Vogel > *To:* Steven Hartland > *Cc:* Michael W. Lucas ; > freebsd-net@freebsd.org > *Sent:* Wednesday, July 20, 2011 6:03 PM > *Subject:* Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE > > Did you eliminate that 7.0 box as part of the issue? Meaning switch to say > a Linux > or 8.2 partner to see if the problem persists or stops? > > > ================================================ > 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 Wed Jul 20 17:31: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 08E081065670 for ; Wed, 20 Jul 2011 17:31:26 +0000 (UTC) (envelope-from prvs=1182c8178b=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 77F588FC0C for ; Wed, 20 Jul 2011 17:31:25 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Wed, 20 Jul 2011 18:30:49 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 20 Jul 2011 18:30:49 +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 md50014238817.msg for ; Wed, 20 Jul 2011 18:30:49 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1182c8178b=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <8169F6D082484BCF8BBA5E31AF4D00BB@multiplay.co.uk> From: "Steven Hartland" To: "Jack Vogel" References: <201107201550.p6KFo9rH032569@freefall.freebsd.org><54AEE240C5F8411A9D4274605DBD14BC@multiplay.co.uk><2976D84B193E4D7DAE6F4C4E28B8F909@multiplay.co.uk><4AED69DE7A474E49BA44470E898ADEDF@multiplay.co.uk> Date: Wed, 20 Jul 2011 18:31:17 +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 Cc: freebsd-net@freebsd.org, "Michael W. Lucas" Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jul 2011 17:31:26 -0000 It stalls on just a basic file scp. Our current test is to scp the freebsd iso to the machine. It won't always do it but it does "seem" like once its had one stall its very much more prone to repeat stalls. Here are some examples of what we see:- FreeBSD-8.2-RELEASE-amd64-disc1.iso 41% 284MB 0.3KB/s - stalled -Read from remote host test01: Operation timed out lost connection world-2011-05-15-09-53-16.tar.gz 100% 67MB 3.4MB/s 00:20 world-2011-05-30-07-35-37.tar.gz 100% 68MB 5.7MB/s 00:12 world-2011-05-05-23-51-00.tar.gz 100% 50MB 3.6MB/s 00:14 world-2011-06-06-14-20-09.tar.gz 100% 81MB 3.7MB/s 00:22 world-2011-06-15-09-10-42.tar.gz 44% 61MB 41.5KB/s - stalled -^world-2011-06-15-09-10-42.tar.gz Failed to restore server, aborting! Write failed: Broken pipe Regards Steve ----- Original Message ----- From: "Jack Vogel" To: "Steven Hartland" Cc: ; "Michael W. Lucas" Sent: Wednesday, July 20, 2011 6:18 PM Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE > Can you formulate a scenario that anyone else can setup and reproduce this? > > Jack > > > On Wed, Jul 20, 2011 at 10:13 AM, Steven Hartland > wrote: > >> ** >> Yep, it stalls 8.2 partners as well :( >> >> ----- Original Message ----- >> *From:* Jack Vogel >> *To:* Steven Hartland >> *Cc:* Michael W. Lucas ; >> freebsd-net@freebsd.org >> *Sent:* Wednesday, July 20, 2011 6:03 PM >> *Subject:* Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE >> >> Did you eliminate that 7.0 box as part of the issue? Meaning switch to say >> a Linux >> or 8.2 partner to see if the problem persists or stops? >> >> >> ================================================ >> 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. >> > _______________________________________________ > 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" > ================================================ 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 Wed Jul 20 18:07: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 F1949106566B for ; Wed, 20 Jul 2011 18:07:29 +0000 (UTC) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: from bewilderbeast.blackhelicopters.org (mwlucas-2-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:b9c::2]) by mx1.freebsd.org (Postfix) with ESMTP id 83D978FC16 for ; Wed, 20 Jul 2011 18:07:29 +0000 (UTC) Received: from bewilderbeast.blackhelicopters.org (localhost [127.0.0.1]) by bewilderbeast.blackhelicopters.org (8.14.4/8.14.4) with ESMTP id p6KI7R66042521; Wed, 20 Jul 2011 14:07:28 -0400 (EDT) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: (from mwlucas@localhost) by bewilderbeast.blackhelicopters.org (8.14.4/8.14.4/Submit) id p6KI7RXx042520; Wed, 20 Jul 2011 14:07:27 -0400 (EDT) (envelope-from mwlucas) Date: Wed, 20 Jul 2011 14:07:27 -0400 From: "Michael W. Lucas" To: Steven Hartland Message-ID: <20110720180727.GA42467@bewilderbeast.blackhelicopters.org> References: <8169F6D082484BCF8BBA5E31AF4D00BB@multiplay.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8169F6D082484BCF8BBA5E31AF4D00BB@multiplay.co.uk> User-Agent: Mutt/1.4.2.3i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (bewilderbeast.blackhelicopters.org [127.0.0.1]); Wed, 20 Jul 2011 14:07:28 -0400 (EDT) Cc: freebsd-net@freebsd.org, Jack Vogel Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jul 2011 18:07:30 -0000 Hi, I'm not seeing a complete stall, just very slow performance. I have two hosts on a shared gigabit Ethernet. One is OpenSolaris, the other FreeBSD. My SCP from the Opensolaris box to the FreeBSD one goes at: 653 MB 00:29 The FreeBSD machine is an Intel SS4200-E. I have a second environment, identical except they're on a 100Mb switch rather than gigabit. Very similar throughput. Any suggestions appreciated. Thanks, ==ml On Wed, Jul 20, 2011 at 06:31:17PM +0100, Steven Hartland wrote: > It stalls on just a basic file scp. Our current test is to scp the freebsd > iso to the machine. It won't always do it but it does "seem" like once its > had > one stall its very much more prone to repeat stalls. > > Here are some examples of what we see:- > > FreeBSD-8.2-RELEASE-amd64-disc1.iso 41% 284MB 0.3KB/s - stalled > -Read from remote host test01: Operation timed out > lost connection > > > world-2011-05-15-09-53-16.tar.gz 100% 67MB 3.4MB/s 00:20 > world-2011-05-30-07-35-37.tar.gz 100% 68MB 5.7MB/s 00:12 > world-2011-05-05-23-51-00.tar.gz 100% 50MB 3.6MB/s 00:14 > world-2011-06-06-14-20-09.tar.gz 100% 81MB 3.7MB/s 00:22 > world-2011-06-15-09-10-42.tar.gz 44% 61MB 41.5KB/s - stalled > -^world-2011-06-15-09-10-42.tar.gz > Failed to restore server, aborting! > Write failed: Broken pipe > > Regards > Steve > > ----- Original Message ----- > From: "Jack Vogel" > To: "Steven Hartland" > Cc: ; "Michael W. Lucas" > > Sent: Wednesday, July 20, 2011 6:18 PM > Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE > > > >Can you formulate a scenario that anyone else can setup and reproduce this? > > > >Jack > > > > > >On Wed, Jul 20, 2011 at 10:13 AM, Steven Hartland > >wrote: > > > >>** > >>Yep, it stalls 8.2 partners as well :( > >> > >>----- Original Message ----- > >>*From:* Jack Vogel > >>*To:* Steven Hartland > >>*Cc:* Michael W. Lucas ; > >>freebsd-net@freebsd.org > >>*Sent:* Wednesday, July 20, 2011 6:03 PM > >>*Subject:* Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE > >> > >>Did you eliminate that 7.0 box as part of the issue? Meaning switch to say > >>a Linux > >>or 8.2 partner to see if the problem persists or stops? > >> > >> > >>================================================ > >>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. > >> > >_______________________________________________ > >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" > > > > ================================================ > 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. -- Michael W. Lucas http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ Latest book: Network Flow Analysis http://www.networkflowanalysis.com/ mwlucas@BlackHelicopters.org, Twitter @mwlauthor From owner-freebsd-net@FreeBSD.ORG Wed Jul 20 19:17:31 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 2881B1065678; Wed, 20 Jul 2011 19:17:31 +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 E0E018FC26; Wed, 20 Jul 2011 19:17:30 +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 p6KJHUO2024196; Wed, 20 Jul 2011 19:17:30 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6KJHUl2024191; Wed, 20 Jul 2011 19:17:30 GMT (envelope-from ae) Date: Wed, 20 Jul 2011 19:17:30 GMT Message-Id: <201107201917.p6KJHUl2024191@freefall.freebsd.org> To: dima_bsd@inbox.lv, ae@FreeBSD.org, freebsd-net@FreeBSD.org From: ae@FreeBSD.org Cc: Subject: Re: kern/143939: [ipfw] [em] ipfw nat and em interface rxcsum 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: Wed, 20 Jul 2011 19:17:31 -0000 Synopsis: [ipfw] [em] ipfw nat and em interface rxcsum problem State-Changed-From-To: open->feedback State-Changed-By: ae State-Changed-When: Wed Jul 20 19:17:03 UTC 2011 State-Changed-Why: Can you still reproduce this on a supported release? http://www.freebsd.org/cgi/query-pr.cgi?pr=143939 From owner-freebsd-net@FreeBSD.ORG Wed Jul 20 19:32: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 30A98106564A for ; Wed, 20 Jul 2011 19:32:14 +0000 (UTC) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: from bewilderbeast.blackhelicopters.org (mwlucas-2-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:b9c::2]) by mx1.freebsd.org (Postfix) with ESMTP id BEB508FC0A for ; Wed, 20 Jul 2011 19:32:13 +0000 (UTC) Received: from bewilderbeast.blackhelicopters.org (localhost [127.0.0.1]) by bewilderbeast.blackhelicopters.org (8.14.4/8.14.4) with ESMTP id p6KJWBLM042896; Wed, 20 Jul 2011 15:32:12 -0400 (EDT) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: (from mwlucas@localhost) by bewilderbeast.blackhelicopters.org (8.14.4/8.14.4/Submit) id p6KJWBpr042895; Wed, 20 Jul 2011 15:32:11 -0400 (EDT) (envelope-from mwlucas) Date: Wed, 20 Jul 2011 15:32:11 -0400 From: "Michael W. Lucas" To: Jack Vogel Message-ID: <20110720193211.GA42886@bewilderbeast.blackhelicopters.org> References: <201107201550.p6KFo9rH032569@freefall.freebsd.org> <54AEE240C5F8411A9D4274605DBD14BC@multiplay.co.uk> <2976D84B193E4D7DAE6F4C4E28B8F909@multiplay.co.uk> <4AED69DE7A474E49BA44470E898ADEDF@multiplay.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (bewilderbeast.blackhelicopters.org [127.0.0.1]); Wed, 20 Jul 2011 15:32:12 -0400 (EDT) Cc: freebsd-net@freebsd.org, Steven Hartland Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jul 2011 19:32:14 -0000 Jack, I think the SCP scenario would be easiest for anyone else to reproduce. If you need a different type of scenario, let me know. I can't put this box into heavy use until I figure this out, so you might as well use me as a guinea pig. Thanks, ==ml On Wed, Jul 20, 2011 at 10:18:32AM -0700, Jack Vogel wrote: > Can you formulate a scenario that anyone else can setup and reproduce this? > > Jack > > > On Wed, Jul 20, 2011 at 10:13 AM, Steven Hartland > wrote: > > > ** > > Yep, it stalls 8.2 partners as well :( > > > > ----- Original Message ----- > > *From:* Jack Vogel > > *To:* Steven Hartland > > *Cc:* Michael W. Lucas ; > > freebsd-net@freebsd.org > > *Sent:* Wednesday, July 20, 2011 6:03 PM > > *Subject:* Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE > > > > Did you eliminate that 7.0 box as part of the issue? Meaning switch to say > > a Linux > > or 8.2 partner to see if the problem persists or stops? > > > > > > ================================================ > > 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. > > -- Michael W. Lucas http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ Latest book: Network Flow Analysis http://www.networkflowanalysis.com/ mwlucas@BlackHelicopters.org, Twitter @mwlauthor From owner-freebsd-net@FreeBSD.ORG Wed Jul 20 20:15: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 48CDA106566B for ; Wed, 20 Jul 2011 20:15:06 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id DC5248FC0C for ; Wed, 20 Jul 2011 20:15:05 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QjdAc-000GTe-DA; Wed, 20 Jul 2011 16:15:02 -0400 Date: Wed, 20 Jul 2011 16:15:02 -0400 From: Gary Palmer To: Paul Keusemann Message-ID: <20110720201502.GA37199@in-addr.com> References: <4E159C5A.5090702@visi.com> <13D65A4C-F874-4970-A070-AA0392416680@mac.com> <4E1C9FEA.2080608@visi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E1C9FEA.2080608@visi.com> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false 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: Wed, 20 Jul 2011 20:15:06 -0000 On Tue, Jul 12, 2011 at 02:26:34PM -0500, Paul Keusemann wrote: > 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. Hi Paul, Even if you are not being NAT'd on the VPN there may be a firewall (or other active network component like a load balancer) with an overflowing state table somewhere at the remote end. We see this frequently where I work with customer networks and the firewall/VPN/network admin denies that its a time out issue so there is likely some device in the network that has a state table and if the connection is idle for a few minutes it gets dropped. Regards, Gary From owner-freebsd-net@FreeBSD.ORG Thu Jul 21 14:14: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 687B61065672 for ; Thu, 21 Jul 2011 14:14:19 +0000 (UTC) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: from bewilderbeast.blackhelicopters.org (mwlucas-2-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:b9c::2]) by mx1.freebsd.org (Postfix) with ESMTP id BFE9F8FC18 for ; Thu, 21 Jul 2011 14:14:18 +0000 (UTC) Received: from bewilderbeast.blackhelicopters.org (localhost [127.0.0.1]) by bewilderbeast.blackhelicopters.org (8.14.4/8.14.4) with ESMTP id p6LEEGQs047305; Thu, 21 Jul 2011 10:14:16 -0400 (EDT) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: (from mwlucas@localhost) by bewilderbeast.blackhelicopters.org (8.14.4/8.14.4/Submit) id p6LEE99E047302; Thu, 21 Jul 2011 10:14:09 -0400 (EDT) (envelope-from mwlucas) Date: Thu, 21 Jul 2011 10:14:09 -0400 From: "Michael W. Lucas" To: Jack Vogel Message-ID: <20110721141409.GC47190@bewilderbeast.blackhelicopters.org> References: <201107201550.p6KFo9rH032569@freefall.freebsd.org> <54AEE240C5F8411A9D4274605DBD14BC@multiplay.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (bewilderbeast.blackhelicopters.org [127.0.0.1]); Thu, 21 Jul 2011 10:14:17 -0400 (EDT) Cc: freebsd-net@freebsd.org, Steven Hartland Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jul 2011 14:14:19 -0000 Jack, After a second reading: is my problem a known em problem? As in, should I stop chasing other possibilities and wait for a solution? Thanks, ==ml On Wed, Jul 20, 2011 at 09:38:53AM -0700, Jack Vogel wrote: > This is an em bug, igb does not share interrupt code with em, furthermore > the adapter > the filer of the bug is using doesn't use MSIX, only one type in the em > driver does, > and I might add lots of heavy users on that adapter have MSIX on without > issues. > > I believe turning MSIX off is just masking whatever your real issue is, if > you wish to > run that way that's fine, but please don't advertise that as a 'fix' in some > general way. > > Regards, > > Jack > > > On Wed, Jul 20, 2011 at 9:07 AM, Steven Hartland wrote: > > > We're seeing tcp stalls under igb under 8.2-RELEASE and 8-STABLE (which > > shares > > some code with em) and the workaround for use is currently adding the > > following > > to /boot/loader.conf > > hw.igb.enable_msix=0 > > > > Might be worth trying that. > > > > Regards > > Steve > > > > ----- Original Message ----- From: "Michael W. Lucas" < > > mwlucas@blackhelicopters.org> > > To: > > Sent: Wednesday, July 20, 2011 4:50 PM > > > > Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE > > > > > > The following reply was made to PR kern/152828; it has been noted by > >> GNATS. > >> > >> From: "Michael W. Lucas" > >> To: bug-followup@FreeBSD.org > >> Cc: rick@sloservers.com > >> Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE > >> Date: Wed, 20 Jul 2011 11:49:08 -0400 > >> > >> I'm seeing the exact same problem here as the original poster. Is > >> anybody looking at this? > >> > >> Running FreeBSD 8.2-RELEASE-p1 amd64, from FreeNAS 8.0 > >> > >> sysctls: > >> dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.1.9 > >> dev.em.0.%driver: em > >> dev.em.0.%location: slot=0 function=0 > >> dev.em.0.%pnpinfo: vendor=0x8086 device=0x108b subvendor=0x8086 > >> subdevice=0x0000 class=0x020000 > >> dev.em.0.%parent: pci1 > >> dev.em.0.nvm: -1 > >> dev.em.0.debug: -1 > >> ... > >> > >> ifconfig: > >> em0: flags=8843 metric 0 mtu > >> 1500 > >> options=219b >> HWCSUM,TSO4,WOL_MAGIC> > >> ether 00:15:17:31:c8:fe > >> inet 139.171.199.13 netmask 0xffffff00 broadcast 139.171.199.255 > >> media: Ethernet autoselect (1000baseT ) > >> status: active > >> > >> dmesg | grep em0 > >> em0: port 0xbc00-0xbc1f mem > >> 0xff6e0000-0xff6fffff irq 16 at device 0.0 on pci1 > >> em0: Using an MSI interrupt > >> em0: [FILTER] > >> em0: Ethernet address: 00:15:17:31:c8:fe > >> > >> > >> > >> > >> -- > >> Michael W. Lucas http://www.MichaelWLucas.com/, > >> http://blather.MichaelWLucas.**com/ > >> Latest book: Network Flow Analysis http://www.**networkflowanalysis.com/ > >> mwlucas@BlackHelicopters.org, Twitter @mwlauthor > >> ______________________________**_________________ > >> 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 > >> " > >> > >> > > ==============================**================== > > 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. > > > > > > ______________________________**_________________ > > 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 > > " > > -- Michael W. Lucas http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ Latest book: Network Flow Analysis http://www.networkflowanalysis.com/ mwlucas@BlackHelicopters.org, Twitter @mwlauthor From owner-freebsd-net@FreeBSD.ORG Thu Jul 21 16:00:34 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 4BE0E106566C; Thu, 21 Jul 2011 16:00:34 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id B2EE98FC0C; Thu, 21 Jul 2011 16:00:33 +0000 (UTC) Received: from [IPv6:2001:470:28:140:11c1:1016:bdbf:959f] ([IPv6:2001:470:28:140:11c1:1016:bdbf:959f]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.4) with ESMTP id p6LG0R4h071439; Thu, 21 Jul 2011 19:00:27 +0300 (EEST) (envelope-from universite@ukr.net) Message-ID: <4E284D09.9060308@ukr.net> Date: Thu, 21 Jul 2011 19:00:09 +0300 From: "Vladislav V. Prodan" 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: net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-92.0 required=5.0 tests=FREEMAIL_FROM,FSL_RU_URL, RDNS_NONE,SPF_SOFTFAIL,TO_NO_BRKTS_DIRECT,T_TO_NO_BRKTS_FREEMAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mary-teresa.otrada.od.ua X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (otrada.od.ua [IPv6:2001:470:28:140::5]); Thu, 21 Jul 2011 19:00:31 +0300 (EEST) Cc: ipfw@freebsd.org Subject: I want to change the ToS / DSCP on FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jul 2011 16:00:34 -0000 Or until just after ng_patch(4)? Inspired by the use of the Yahoo-balancing traffic http://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk45.nanog51-Schaumann.pdf -- Vladislav V. Prodan VVP24-UANIC +380[67]4584408 +380[99]4060508 vlad11@jabber.ru From owner-freebsd-net@FreeBSD.ORG Thu Jul 21 18:07: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 60C581065673 for ; Thu, 21 Jul 2011 18:07:47 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 39B3C8FC0C for ; Thu, 21 Jul 2011 18:07:46 +0000 (UTC) Received: by pvg11 with SMTP id 11so1752157pvg.13 for ; Thu, 21 Jul 2011 11:07:46 -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:content-transfer-encoding; bh=mDF4cZyBHRSj87O7C9B5pnJG2krN+FxAFOpjOg1e8Cs=; b=Egs+maasvxuunR3S42gW+GzjrIxH4A0/Pz5d/SmKJv0ThdliVDV1IJUneJ4e/s3mhz fAA+eP61psxiRKjX93t7AlBX9Jl27TvyVVIl4gU0YiotnBzqd3k4jeXti4iwPxSwaQvm E018Stfa4G5HvP+Xw7fMqyk0sRrC34HztUMZo= MIME-Version: 1.0 Received: by 10.68.26.196 with SMTP id n4mr684312pbg.75.1311271666371; Thu, 21 Jul 2011 11:07:46 -0700 (PDT) Received: by 10.68.56.8 with HTTP; Thu, 21 Jul 2011 11:07:46 -0700 (PDT) In-Reply-To: <54AEE240C5F8411A9D4274605DBD14BC@multiplay.co.uk> References: <201107201550.p6KFo9rH032569@freefall.freebsd.org> <54AEE240C5F8411A9D4274605DBD14BC@multiplay.co.uk> Date: Thu, 21 Jul 2011 14:07:46 -0400 Message-ID: From: Arnaud Lacombe To: Steven Hartland Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, "Michael W. Lucas" Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jul 2011 18:07:47 -0000 Hi, On Wed, Jul 20, 2011 at 12:07 PM, Steven Hartland wrote: > We're seeing tcp stalls under igb under 8.2-RELEASE and 8-STABLE (which > shares > some code with em) and the workaround for use is currently adding the > following > to /boot/loader.conf > hw.igb.enable_msix=3D0 > > Might be worth trying that. > Unless error of my part, you were pointed out in [0] that you had TCP retransmission issue and you never follow-up that mail. - Arnaud [0]: http://www.mail-archive.com/freebsd-net@freebsd.org/msg37292.html > =A0 Regards > =A0 Steve > > ----- Original Message ----- From: "Michael W. Lucas" > > To: > Sent: Wednesday, July 20, 2011 4:50 PM > Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE > > >> The following reply was made to PR kern/152828; it has been noted by >> GNATS. >> >> From: "Michael W. Lucas" >> To: bug-followup@FreeBSD.org >> Cc: rick@sloservers.com >> Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE >> Date: Wed, 20 Jul 2011 11:49:08 -0400 >> >> I'm seeing the exact same problem here as the original poster. Is >> anybody looking at this? >> >> Running FreeBSD 8.2-RELEASE-p1 amd64, from FreeNAS 8.0 >> >> sysctls: >> dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.1.9 >> dev.em.0.%driver: em >> dev.em.0.%location: slot=3D0 function=3D0 >> dev.em.0.%pnpinfo: vendor=3D0x8086 device=3D0x108b subvendor=3D0x8086 >> subdevice=3D0x0000 class=3D0x020000 >> dev.em.0.%parent: pci1 >> dev.em.0.nvm: -1 >> dev.em.0.debug: -1 >> ... >> >> ifconfig: >> em0: flags=3D8843 metric 0 mtu 1= 500 >> >> =A0options=3D219b >> =A0 =A0 =A0 =A0ether 00:15:17:31:c8:fe >> =A0 =A0 =A0 =A0inet 139.171.199.13 netmask 0xffffff00 broadcast 139.171.= 199.255 >> =A0 =A0 =A0 =A0media: Ethernet autoselect (1000baseT ) >> =A0 =A0 =A0 =A0status: active >> >> dmesg | grep em0 >> em0: port 0xbc00-0xbc1f mem >> 0xff6e0000-0xff6fffff irq 16 at device 0.0 on pci1 >> em0: Using an MSI interrupt >> em0: [FILTER] >> em0: Ethernet address: 00:15:17:31:c8:fe >> >> >> >> >> -- >> Michael W. Lucas http://www.MichaelWLucas.com/, >> http://blather.MichaelWLucas.com/ >> Latest book: Network Flow Analysis http://www.networkflowanalysis.com/ >> mwlucas@BlackHelicopters.org, Twitter @mwlauthor >> _______________________________________________ >> 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" >> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This e.mail is private and confidential between Multiplay (UK) Ltd. and t= he > person or entity to whom it is addressed. In the event of misdirection, t= he > 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. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Jul 21 20:37:36 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 292CB1065672; Thu, 21 Jul 2011 20:37:36 +0000 (UTC) (envelope-from jlott@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 D87648FC08; Thu, 21 Jul 2011 20:37:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id C39018BC020; Thu, 21 Jul 2011 16:22:35 -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 YDGr3wCaIfrT; Thu, 21 Jul 2011 16:22:34 -0400 (EDT) Received: from jlott-mac.arriad.com (fw.arriad.com [10.0.0.16]) by zimbra.averesystems.com (Postfix) with ESMTPSA id 619468BC003; Thu, 21 Jul 2011 16:22:34 -0400 (EDT) From: Jeremiah Lott Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Jul 2011 16:19:59 -0400 Message-Id: <44626428-CF14-4B20-AB57-6D4E8F4678AE@averesystems.com> To: freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: rmacklem@FreeBSD.org Subject: LOR with nfsclient "sillyrename" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jul 2011 20:37:36 -0000 We're seeing nfsclient deadlocks with what looks like lock order = reversal after removing a "silly rename". It is fairly rare, but we've = seen it happen a few times. I included relevant back traces from an = occurrence. =46rom what I can see, nfs_inactive() is called with the = vnode locked. If there is a silly-rename, it will call vrele() on its = parent directory, which can potentially try to lock the parent = directory. Since this is the opposite order of the lock acquisition in = lookup, it can deadlock. This happened in a FreeBSD7 build, but I = looked through freebsd head and didn't see any change that addressed = this. Anyone seen this before? Jeremiah Lott Avere Systems (kgdb) thread 132 [Switching to thread 132 (Thread 100437)]#10 0xffffffff804e794e in vget = ( vp=3D0xffffff019bafe5e8, flags=3D8194, td=3D0xffffff00096e16e0) at ../../../kern/vfs_subr.c:2070 2070 if ((error =3D vn_lock(vp, flags | LK_INTERLOCK, td)) !=3D= 0) { (kgdb) bt #0 sched_switch (td=3D0xffffff00096e16e0, newtd=3D0xffffff00021f46e0, = flags=3D1) at ../../../kern/sched_4bsd.c:928 #1 0xffffffff80477a1c in mi_switch (flags=3D1, newtd=3D0x0) at ../../../kern/kern_synch.c:444 #2 0xffffffff804a032b in sleepq_switch (wchan=3DVariable "wchan" is not = available. ) at ../../../kern/subr_sleepqueue.c:535 #3 0xffffffff804a05f1 in sleepq_catch_signals = (wchan=3D0xffffff019bafe680) at ../../../kern/subr_sleepqueue.c:455 #4 0xffffffff804a0ba6 in sleepq_wait_sig (wchan=3DVariable "wchan" is = not available. ) at ../../../kern/subr_sleepqueue.c:650 #5 0xffffffff80477f15 in _sleep (ident=3D0xffffff019bafe680,=20 lock=3D0xffffffff80f58020, priority=3D336, wmesg=3D0xffffffff8077df5c = "nfs",=20 timo=3D0) at ../../../kern/kern_synch.c:224 #6 0xffffffff8045eef0 in acquire (lkpp=3D0xffffffffd1475420, = extflags=3DVariable "extflags" is not available. ) at ../../../kern/kern_lock.c:151 #7 0xffffffff8045f228 in _lockmgr (lkp=3D0xffffff019bafe680, = flags=3DVariable "flags" is not available. ) at ../../../kern/kern_lock.c:384 #8 0xffffffff806fefda in VOP_LOCK1_APV (vop=3D0xffffffff8095f360,=20 a=3D0xffffffffd14754c0) at vnode_if.c:1618 #9 0xffffffff804f106f in _vn_lock (vp=3D0xffffff019bafe5e8, flags=3D2,=20= td=3D0xffffff00096e16e0, file=3D0xffffffff80772758 = "../../../kern/vfs_subr.c",=20 line=3D2070) at vnode_if.h:851 #10 0xffffffff804e794e in vget (vp=3D0xffffff019bafe5e8, flags=3D8194,=20= td=3D0xffffff00096e16e0) at ../../../kern/vfs_subr.c:2070 ---Type to continue, or q to quit--- #11 0xffffffff804db125 in vfs_hash_get (mp=3D0xffffff00049e1000,=20 hash=3D2562259366, flags=3DVariable "flags" is not available. ) at ../../../kern/vfs_hash.c:81 #12 0xffffffff80552198 in nfs_nget (mntp=3D0xffffff00049e1000,=20 fhp=3D0xffffff0d97160578, fhsize=3D48, npp=3D0xffffffffd14757d0, = flags=3D2) at ../../../nfsclient/nfs_node.c:120 #13 0xffffffff8056084b in nfs_lookup (ap=3DVariable "ap" is not = available. ) at ../../../nfsclient/nfs_vnops.c:950 #14 0xffffffff806ffa84 in VOP_LOOKUP_APV (vop=3D0xffffffff8096a980,=20 a=3D0xffffffffd14758e0) at vnode_if.c:99 #15 0xffffffff804dc16d in lookup (ndp=3D0xffffffffd1475a00) at = vnode_if.h:57 #16 0xffffffff804dce94 in namei (ndp=3D0xffffffffd1475a00) at ../../../kern/vfs_lookup.c:215 #17 0xffffffff804ebf4e in kern_unlink (td=3D0xffffff00096e16e0,=20 path=3D0x80e815178
,=20 pathseg=3DUIO_USERSPACE) at ../../../kern/vfs_syscalls.c:1670 #18 0xffffffff8066d756 in syscall (frame=3D0xffffffffd1475c80) at ../../../amd64/amd64/trap.c:939 #19 0xffffffff8065409b in Xfast_syscall () at ../../../amd64/amd64/exception.S:339 #20 0x00000008014524bc in ?? () (kgdb) up 6 #6 0xffffffff8045eef0 in acquire (lkpp=3D0xffffffffd1475420, = extflags=3DVariable "extflags" is not available. ) at ../../../kern/kern_lock.c:151 151 error =3D msleep(lkp, lkp->lk_interlock, = lkp->lk_prio, (kgdb) print *lkp =20 $7 =3D {lk_object =3D {lo_name =3D 0xffffffff8077df5c "nfs",=20 lo_type =3D 0xffffffff8077df5c "nfs", lo_flags =3D 70844416,=20 lo_witness_data =3D {lod_list =3D {stqe_next =3D 0x0}, lod_witness =3D= 0x0}},=20 lk_interlock =3D 0xffffffff80f58020, lk_flags =3D 33816640, = lk_sharecount =3D 0,=20 lk_waitcount =3D 1, lk_exclusivecount =3D 1, lk_prio =3D 336, lk_timo = =3D 51,=20 lk_lockholder =3D 0xffffff0180998000, lk_newlock =3D 0x0} (kgdb) print td No symbol "td" in current context. (kgdb) thread 134 [Switching to thread 134 (Thread 100765)]#0 sched_switch ( td=3D0xffffff0180998000, newtd=3D0xffffff00021f4370, flags=3D1) at ../../../kern/sched_4bsd.c:928 928 if (PMC_PROC_IS_USING_PMCS(td->td_proc)) (kgdb) bt #0 sched_switch (td=3D0xffffff0180998000, newtd=3D0xffffff00021f4370, = flags=3D1) at ../../../kern/sched_4bsd.c:928 #1 0xffffffff80477a1c in mi_switch (flags=3D1, newtd=3D0x0) at ../../../kern/kern_synch.c:444 #2 0xffffffff804a032b in sleepq_switch (wchan=3DVariable "wchan" is not = available. ) at ../../../kern/subr_sleepqueue.c:535 #3 0xffffffff804a05f1 in sleepq_catch_signals = (wchan=3D0xffffff0009b90a70) at ../../../kern/subr_sleepqueue.c:455 #4 0xffffffff804a0ba6 in sleepq_wait_sig (wchan=3DVariable "wchan" is = not available. ) at ../../../kern/subr_sleepqueue.c:650 #5 0xffffffff80477f15 in _sleep (ident=3D0xffffff0009b90a70,=20 lock=3D0xffffffff80f57c60, priority=3D336, wmesg=3D0xffffffff8077df5c = "nfs",=20 timo=3D0) at ../../../kern/kern_synch.c:224 #6 0xffffffff8045eef0 in acquire (lkpp=3D0xffffffffd1ade690, = extflags=3DVariable "extflags" is not available. ) at ../../../kern/kern_lock.c:151 #7 0xffffffff8045f68e in _lockmgr (lkp=3D0xffffff0009b90a70, = flags=3DVariable "flags" is not available. ) at ../../../kern/kern_lock.c:391 #8 0xffffffff806fefda in VOP_LOCK1_APV (vop=3D0xffffffff8095f360,=20 a=3D0xffffffffd1ade730) at vnode_if.c:1618 #9 0xffffffff804f106f in _vn_lock (vp=3D0xffffff0009b909d8, flags=3D2,=20= td=3D0xffffff0180998000, file=3D0xffffffff80772758 = "../../../kern/vfs_subr.c",=20 line=3D2165) at vnode_if.h:851 #10 0xffffffff804e72a7 in vrele (vp=3D0xffffff0009b909d8) at ../../../kern/vfs_subr.c:2165 ---Type to continue, or q to quit--- #11 0xffffffff80551f11 in nfs_inactive (ap=3D0xffffffffd1ade860) at ../../../nfsclient/nfs_node.c:216 #12 0xffffffff806fdfa8 in VOP_INACTIVE_APV (vop=3DVariable "vop" is not = available. ) at vnode_if.c:1513 #13 0xffffffff804e26b8 in vinactive (vp=3D0xffffff019bafe5e8,=20 td=3D0xffffff0180998000) at vnode_if.h:796 #14 0xffffffff804e713e in vput (vp=3D0xffffff019bafe5e8) at ../../../kern/vfs_subr.c:2232 #15 0xffffffff804f197b in vn_close (vp=3D0xffffff019bafe5e8, = flags=3DVariable "flags" is not available. ) at ../../../kern/vfs_vnops.c:295 #16 0xffffffff804f1a20 in vn_closefile (fp=3D0xffffff0180dab000,=20 td=3D0xffffff0180998000) at ../../../kern/vfs_vnops.c:867 #17 0xffffffff80446838 in fdrop (fp=3D0xffffff0180dab000, = td=3D0xffffff0180998000) at file.h:299 #18 0xffffffff804480f9 in closef (fp=3D0xffffff0180dab000, = td=3D0xffffff0180998000) at ../../../kern/kern_descrip.c:2033 #19 0xffffffff804486e0 in kern_close (td=3D0xffffff0180998000, fd=3D53) at ../../../kern/kern_descrip.c:1125 #20 0xffffffff8066d756 in syscall (frame=3D0xffffffffd1adec80) at ../../../amd64/amd64/trap.c:939 #21 0xffffffff8065409b in Xfast_syscall () at ../../../amd64/amd64/exception.S:339 #22 0x00000008014631fc in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) up 6 #6 0xffffffff8045eef0 in acquire (lkpp=3D0xffffffffd1ade690, = extflags=3DVariable "extflags" is not available. ) at ../../../kern/kern_lock.c:151 151 error =3D msleep(lkp, lkp->lk_interlock, = lkp->lk_prio, (kgdb) print *lkp $8 =3D {lk_object =3D {lo_name =3D 0xffffffff8077df5c "nfs",=20 lo_type =3D 0xffffffff8077df5c "nfs", lo_flags =3D 70844416,=20 lo_witness_data =3D {lod_list =3D {stqe_next =3D 0x0}, lod_witness =3D= 0x0}},=20 lk_interlock =3D 0xffffffff80f57c60, lk_flags =3D 33947712, = lk_sharecount =3D 0,=20 lk_waitcount =3D 2, lk_exclusivecount =3D 1, lk_prio =3D 336, lk_timo = =3D 51,=20 lk_lockholder =3D 0xffffff00096e16e0, lk_newlock =3D 0x0}= From owner-freebsd-net@FreeBSD.ORG Fri Jul 22 06:28: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 9A197106564A; Fri, 22 Jul 2011 06:28:54 +0000 (UTC) (envelope-from rea@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 1431B8FC13; Fri, 22 Jul 2011 06:28:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codelabs.ru; s=two; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=0JzVxuJQaoa/jSAWGlvjyr3BxaAxrzKqb8kFCLe+lsc=; b=fk5IFiFSbs6pANztcWC5Et0wulinLgbGnnKC95F5QgJLq0ScpkG9R1/AR9a9qeXNXnslVml2Fs4w3ye/RbwGmWr0++XpOAsGJbfGUa+jwQvpJIltcZOjudN0Ccw2i8ZGlvtzTEKQr2CkB+jEXxO6HRWUu76Na7vfF7y3jAof4bEMjnAKMZaQw5hhldUQ6cbNXE4ikRLVU6IovGJLoWbOch2YOTeYdZOlq8PeIea+triGhArled/Q8FbJIjlzs/f2sfsO+3fO3BWj+0v0VM55fwO2UB2wOwyzsoEDB1PFttfFKfRU6LHoTV0zZtV/CYQOts+vs4ss5Tvwe+Qt9QFxIw==; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1Qk9EC-000AqV-A2; Fri, 22 Jul 2011 10:28:52 +0400 Date: Fri, 22 Jul 2011 10:28:50 +0400 From: Eygene Ryabinkin To: Daniel Braniss Message-ID: References: <20110718203215.GM54929@MacBook-Eygene-Ryabinkin.local> <20110719172455.GP54929@MacBook-Eygene-Ryabinkin.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tsOsTdHNUZQcU9Ye" Content-Disposition: inline In-Reply-To: Sender: rea@codelabs.ru Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: broadcast oddity X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jul 2011 06:28:54 -0000 --tsOsTdHNUZQcU9Ye Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Wed, Jul 20, 2011 at 12:34:38PM +0300, Daniel Braniss wrote: > from the diskless: > els-01# ifconfig > vr0: flags=3D8843 metric 0 mtu 15= 00 > options=3D8280b > ether 00:0d:b9:22:57:18 > inet 132.65.91.1 netmask 0xfffff000 broadcast 132.65.95.255 > media: Ethernet autoselect (100baseTX ) > status: active > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D3 > inet 127.0.0.1 netmask 0xff000000=20 > els-01# netstat -rn > Routing tables >=20 > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 132.65.80.1 UG 0 16606 vr0 > 127.0.0.1 link#4 UH 0 36 lo0 > 132.65.80.0/20 link#1 U 0 86612 vr0 > 132.65.91.1 link#1 UHS 0 12 lo0 >=20 > from the non-diskless: > wrap-1# ifconfig > sis0: flags=3D8943 metric= 0 mtu=20 > 1500 > options=3D83808 > ether 00:0d:b9:00:72:a8 > inet 132.65.80.181 netmask 0xfffff000 broadcast 132.65.95.255 > media: Ethernet autoselect (100baseTX ) > status: active > sis1: flags=3D8802 metric 0 mtu 1500 > options=3D83808 > ether 00:0d:b9:00:72:a9 > media: Ethernet autoselect (none) > status: no carrier > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D3 > inet 127.0.0.1 netmask 0xff000000=20 >=20 > wrap-1# netstat -rn > Routing tables >=20 > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 132.65.80.1 UGS 0 16936 sis0 > 127.0.0.1 link#4 UH 0 76 lo0 > 132.65.80.0/20 link#1 U 0 67433 sis0 > 132.65.80.181 link#1 UHS 0 0 lo0 The only difference I see is the absence of the 'S' flag on the default route for the diskless case. Will try to create the testbed. > > Yes, it is. But ip_output.c has the following code, > > {{{ > > if (rte->rt_flags & RTF_GATEWAY) > > dst =3D3D (struct sockaddr_in *)rte->rt_gateway; > > if (rte->rt_flags & RTF_HOST) > > isbroadcast =3D3D (rte->rt_flags & RTF_BROADCAS= T); > > else > > isbroadcast =3D3D in_broadcast(dst->sin_addr, i= fp); > > }}} > >=20 > > So, if the route that is selected is the gateway, then there will be > > no broadcast on the L2. At least in my understanding of the code. > > Thus, I am interested in the routing tables and route flags. >=20 > so it boils down to a problem in selecting the route? More-or-less so: for default gateways there will never be any L2-broadcasts, for host routes the L2-broadcasts are governed by the 'B' route flag and for other routes the destination address governs the behaviour (INADDR_ANY & INADDR_BROADCAST as the destination will enable L2-broadcast unconditionally /but most likely we will hit the default route earlier for this case/, interface broadcast address /132.65.95.255 in your case/ will enable L2-brodcast via the corresponding interface). --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --tsOsTdHNUZQcU9Ye Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iF4EAREIAAYFAk4pGKIACgkQFq+eroFS7Pu6QAD+JAIkX+Rv5wNg4mFn3+nh9ost FXzLZwEAjbdAiLqWAn0A/iyXAYHFpLK5DE5RfQCrSxcFojKaOkotKazyrncZpvU+ =b8c0 -----END PGP SIGNATURE----- --tsOsTdHNUZQcU9Ye-- From owner-freebsd-net@FreeBSD.ORG Fri Jul 22 08:11: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 0A125106564A for ; Fri, 22 Jul 2011 08:11:47 +0000 (UTC) (envelope-from achilov-rn@askd.ru) Received: from master.askd.ru (master.askd.ru [80.242.75.6]) by mx1.freebsd.org (Postfix) with ESMTP id 757E58FC18 for ; Fri, 22 Jul 2011 08:11:46 +0000 (UTC) Received: from to-594.askd.gmbh (sentry [192.168.1.94]) by master.askd.ru (8.14.5/8.14.5) with ESMTP id p6M7sDTK086634 for ; Fri, 22 Jul 2011 14:54:13 +0700 (NOVT) (envelope-from achilov-rn@askd.ru) From: "Rashid N. Achilov" Organization: =?koi8-r?b?7+/v?= "=?koi8-r?b?4fMt88nT1MXNwQ==?= =?koi8-r?b?IOvPzdDMxcvT?=" To: freebsd-net@freebsd.org Date: Fri, 22 Jul 2011 14:54:11 +0700 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201107221454.11469.achilov-rn@askd.ru> Subject: strange ping on local address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Achilov, Rashid" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 08:11:47 -0000 When I try to ping local interface - ping missed! When I try to ping this interface with -S key (specified the same address) - working. What's a bug? In RELENG_7 worked. local interface on box: em0: flags=8943 metric 0 mtu 1500 options=219b ether 00:xx:xx:xx:xx:xx inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active ping ordinary: master:[root] 105>ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 data bytes ^C --- 192.168.1.1 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss ping with -S key: master:[root] 106>ping -S 192.168.1.1 192.168.1.1 PING 192.168.1.1 (192.168.1.1) from 192.168.1.1: 56 data bytes 64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.022 ms 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.030 ms ^C --- 192.168.1.1 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.022/0.026/0.030/0.004 ms master:[root] 103>uname -a FreeBSD master.askd.ru 8.2-STABLE FreeBSD 8.2-STABLE #1: Fri Jul 15 18:23:18 NOVST 2011 root@master-new.askd.gmbh:/usr/obj/usr/src/sys/Master i386 What's a terrible? I'm understand, that ping "itself" is rarely situation, but it worked in 7.x! -- With Best Regards. Rashid N. Achilov (RNA1-RIPE), JID: citycat4@jabber.infos.ru OOO "ACK" telecommunications administrator, e-mail: achilov-rn [at] askd.ru PGP: 83 CD E2 A7 37 4A D5 81 D6 D6 52 BF C9 2F 85 AF 97 BE CB 0A From owner-freebsd-net@FreeBSD.ORG Fri Jul 22 08:29: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 208261065670 for ; Fri, 22 Jul 2011 08:29:16 +0000 (UTC) (envelope-from ivsan@ngs.ru) Received: from smtpout17.ngs.ru (smtpout17.ngs.ru [195.93.186.223]) by mx1.freebsd.org (Postfix) with ESMTP id 74DA78FC0C for ; Fri, 22 Jul 2011 08:29:15 +0000 (UTC) Received: from smtpout.ngs.ru (imx2.in.ngs.ru [172.16.0.5]) by smtpout17.ngs.ru (smtpout17.ngs.ru) with ESMTP id 4E9F871DA0C7 for ; Fri, 22 Jul 2011 14:59:59 +0700 (NOVST) Received: from mx14.intranet.ru (unknown [172.16.7.2]) by mail.ngs.ru (smtp) with ESMTP id 226E83A453556 for ; Fri, 22 Jul 2011 15:09:41 +0700 (NOVST) Received: from mx16.intranet.ru (unknown [172.16.7.4]) by mx14.intranet.ru (mx14.intranet.ru) with ESMTP id 1FF68FB56 for ; Fri, 22 Jul 2011 15:09:41 +0700 (NOVST) Received: from [80.242.66.33] (account ivsan@ngs.ru) by mx16.intranet.ru (CommuniGate Pro WebUser 4.3.11) with HTTP id 8285764 for freebsd-net@freebsd.org; Fri, 22 Jul 2011 12:09:41 +0400 From: "Ivan Alexandrovich" To: freebsd-net@freebsd.org Date: Fri, 22 Jul 2011 15:09:41 +0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Subject: Ethernet link status on i82576 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jul 2011 08:29:16 -0000 Hi I've just noticed the following problem with intel's quad-port card based on i82756 chip: When the ethernet link goes down igb driver doesn't detect link status change. When the cable is unplugged ifconfig(8) still shows: igb5: flags=8802 metric 0 mtu 1500 options=1bb ether 00:1b:21:81:e9:57 media: Ethernet autoselect (1000baseT ) status: active Ethernet card: E1G44ET2 Motherboard: Intel S550WBV OS: FreeBSD 8.2-RELEASE, FreeBSD-9.0 (201105 snapshot) Driver: igb-2.0.7 (stock kernel), Intel's igb-2.2.3 On linux with 2.6.38 kernel link status detection on E1G44ET2 works fine. Tried to use debugging in intel's driver (set DEBUG_INIT* defines in if_igb.h to "1") but had no success. When the ethernet cable is plugged in it logs: igb_media_status: begin link state changed to UP ioctl rcv'd: SIOCxIFMEDIA (Get/Set Interface Media) igb_media_status: begin ioctl rcv'd: SIOCxIFMEDIA (Get/Set Interface Media) igb_media_status: begin But when I detach cable the driver remains silent. Some addtitional data concerning the issue included bellow. Thanks, Ivan FreeBSD 8.2-RELEASE, stock kernel's if_igb driver 2.0.7, dmesg excerpt ---------------------------------------------------------------------- igb5: port 0x1000-0x101f mem 0xb2400000-0xb241ffff,0xb1c00000-0xb1ffffff,0xb2440000- igb5: Using MSIX interrupts with 9 vectors igb5: [ITHREAD] igb5: [ITHREAD] igb5: [ITHREAD] igb5: [ITHREAD] igb5: [ITHREAD] igb5: [ITHREAD] igb5: [ITHREAD] igb5: [ITHREAD] igb5: [ITHREAD] igb5: Ethernet address: 00:1b:21:81:e9:57 .. igb5: link state changed to UP linux, /usr/sbin/lspci output ----------------------------- 07:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) 07:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) 0a:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) 0a:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) linux, kernel 2.6.38, dmesg excerpt ----------------------------------- igb 0000:0a:00.1: PCI INT B -> GSI 37 (level, low) -> IRQ 37 igb 0000:0a:00.1: setting latency timer to 64 igb 0000:0a:00.1: irq 118 for MSI/MSI-X igb 0000:0a:00.1: irq 119 for MSI/MSI-X igb 0000:0a:00.1: irq 120 for MSI/MSI-X igb 0000:0a:00.1: irq 121 for MSI/MSI-X igb 0000:0a:00.1: irq 122 for MSI/MSI-X igb 0000:0a:00.1: irq 123 for MSI/MSI-X igb 0000:0a:00.1: irq 124 for MSI/MSI-X igb 0000:0a:00.1: irq 125 for MSI/MSI-X igb 0000:0a:00.1: irq 126 for MSI/MSI-X igb 0000:0a:00.1: 0 vfs allocated igb 0000:0a:00.1: Intel(R) Gigabit Ethernet Network Connection igb 0000:0a:00.1: eth5: (PCIe:2.5Gb/s:Width x4) 00:1b:21:81:e9:57 igb 0000:0a:00.1: eth5: PBA No: E91609-003 igb 0000:0a:00.1: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s) igb 0000:0a:00.1: DCA enabled .. igb: eth4 NIC Link is Down igb: eth4 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX igb: eth7 NIC Link is Down igb: eth7 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX From owner-freebsd-net@FreeBSD.ORG Fri Jul 22 11:21:30 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 E595B1065672 for ; Fri, 22 Jul 2011 11:21:30 +0000 (UTC) (envelope-from vladimir.budnev@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id A2E278FC0C for ; Fri, 22 Jul 2011 11:21:30 +0000 (UTC) Received: by vxg33 with SMTP id 33so2101637vxg.13 for ; Fri, 22 Jul 2011 04:21:29 -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=hb7nyDUo5U7Xjxw54KcSxDzBTWIyxjCOoX70JSulOIc=; b=hgBlwSvgsoiPEgOmgIPwJBebOZlxdZjazFd/3dpoC9ce2ledbm9MJ8u2+dkUmVHvTN u4RKMY4cz2uiw1d9aw/H1HY5nrHmGg3CxNgnu9X/4/O/BBWhI2RKS3pEP5anQOYim6id coZ834/OaXsI+65VJBsBXxWLsLN2KEXbNUtkE= MIME-Version: 1.0 Received: by 10.52.173.45 with SMTP id bh13mr1406691vdc.3.1311333689786; Fri, 22 Jul 2011 04:21:29 -0700 (PDT) Received: by 10.220.178.129 with HTTP; Fri, 22 Jul 2011 04:21:29 -0700 (PDT) Date: Fri, 22 Jul 2011 15:21:29 +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: What does define COMMENT_ONLY mean? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jul 2011 11:21:31 -0000 Hello! What does this define COMMENT_ONLY mean and what for it is used? Iv met such one in if_arp.h source in freebsd kernel, but cant get such strange if in arp header structure. -----------------------------------example struct arphdr { <...> /* * The remaining fields are variable in size, * according to the sizes above. */ #ifdef COMMENT_ONLY u_char ar_sha[]; /* sender hardware address */ u_char ar_spa[]; /* sender protocol address */ u_char ar_tha[]; /* target hardware address */ u_char ar_tpa[]; /* target protocol address */ #endif }; From owner-freebsd-net@FreeBSD.ORG Fri Jul 22 12:55:12 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 892181065670; Fri, 22 Jul 2011 12:55:12 +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 4107D8FC12; Fri, 22 Jul 2011 12:55:12 +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 CB80746B03; Fri, 22 Jul 2011 08:55:11 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3D55C8A02C; Fri, 22 Jul 2011 08:55:11 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Fri, 22 Jul 2011 08:55:10 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <44626428-CF14-4B20-AB57-6D4E8F4678AE@averesystems.com> In-Reply-To: <44626428-CF14-4B20-AB57-6D4E8F4678AE@averesystems.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107220855.10774.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 22 Jul 2011 08:55:11 -0400 (EDT) Cc: Jeremiah Lott , rmacklem@freebsd.org Subject: Re: LOR with nfsclient "sillyrename" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jul 2011 12:55:12 -0000 On Thursday, July 21, 2011 4:19:59 pm Jeremiah Lott wrote: > We're seeing nfsclient deadlocks with what looks like lock order reversal after removing a "silly rename". It is fairly rare, but we've seen it happen a few times. I included relevant back traces from an occurrence. From what I can see, nfs_inactive() is called with the vnode locked. If there is a silly-rename, it will call vrele() on its parent directory, which can potentially try to lock the parent directory. Since this is the opposite order of the lock acquisition in lookup, it can deadlock. This happened in a FreeBSD7 build, but I looked through freebsd head and didn't see any change that addressed this. Anyone seen this before? I haven't seen this before, but your analysis looks correct to me. Perhaps the best fix would be to defer the actual freeing of the sillyrename to an asynchronous task? Maybe something like this (untested, uncompiled): Index: nfsclient/nfsnode.h =================================================================== --- nfsclient/nfsnode.h (revision 224254) +++ nfsclient/nfsnode.h (working copy) @@ -36,6 +36,7 @@ #ifndef _NFSCLIENT_NFSNODE_H_ #define _NFSCLIENT_NFSNODE_H_ +#include #if !defined(_NFSCLIENT_NFS_H_) && !defined(_KERNEL) #include #endif @@ -45,8 +46,10 @@ * can be removed by nfs_inactive() */ struct sillyrename { + struct task s_task; struct ucred *s_cred; struct vnode *s_dvp; + struct vnode *s_vp; int (*s_removeit)(struct sillyrename *sp); long s_namlen; char s_name[32]; Index: nfsclient/nfs_vnops.c =================================================================== --- nfsclient/nfs_vnops.c (revision 224254) +++ nfsclient/nfs_vnops.c (working copy) @@ -1757,7 +1757,6 @@ { /* * Make sure that the directory vnode is still valid. - * XXX we should lock sp->s_dvp here. */ if (sp->s_dvp->v_type == VBAD) return (0); @@ -2754,8 +2753,10 @@ M_NFSREQ, M_WAITOK); sp->s_cred = crhold(cnp->cn_cred); sp->s_dvp = dvp; + sp->s_vp = vp; sp->s_removeit = nfs_removeit; VREF(dvp); + vhold(vp); /* * Fudge together a funny name. Index: nfsclient/nfs_node.c =================================================================== --- nfsclient/nfs_node.c (revision 224254) +++ nfsclient/nfs_node.c (working copy) @@ -47,6 +47,7 @@ #include #include #include +#include #include #include @@ -185,6 +186,26 @@ return (0); } +static void +nfs_freesillyrename(void *arg, int pending) +{ + struct sillyrename *sp; + + sp = arg; + vn_lock(sp->s_dvp, LK_SHARED | LK_RETRY); + vn_lock(sp->s_vp, LK_EXCLUSIVE | LK_RETRY); + (void)nfs_vinvalbuf(ap->a_vp, 0, td, 1); + /* + * Remove the silly file that was rename'd earlier + */ + (sp->s_removeit)(sp); + crfree(sp->s_cred); + vput(sp->s_dvp); + VOP_UNLOCK(sp->s_vp, 0); + vdrop(sp->s_vp); + free((caddr_t)sp, M_NFSREQ); +} + int nfs_inactive(struct vop_inactive_args *ap) { @@ -200,15 +221,9 @@ } else sp = NULL; if (sp) { + TASK_INIT(&sp->task, 0, nfs_freesillyrename, sp); + taskqueue_enqueue(taskqueue_thread, &sp->task); mtx_unlock(&np->n_mtx); - (void)nfs_vinvalbuf(ap->a_vp, 0, td, 1); - /* - * Remove the silly file that was rename'd earlier - */ - (sp->s_removeit)(sp); - crfree(sp->s_cred); - vrele(sp->s_dvp); - free((caddr_t)sp, M_NFSREQ); mtx_lock(&np->n_mtx); } np->n_flag &= NMODIFIED; -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Jul 22 13:12: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 39C241065672; Fri, 22 Jul 2011 13:12:06 +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 CAFE58FC08; Fri, 22 Jul 2011 13:12:05 +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 p6MDBxh8081365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jul 2011 16:11:59 +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 p6MDBxYO025652; Fri, 22 Jul 2011 16:11:59 +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 p6MDBxi1025651; Fri, 22 Jul 2011 16:11:59 +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: Fri, 22 Jul 2011 16:11:59 +0300 From: Kostik Belousov To: John Baldwin Message-ID: <20110722131159.GR17489@deviant.kiev.zoral.com.ua> References: <44626428-CF14-4B20-AB57-6D4E8F4678AE@averesystems.com> <201107220855.10774.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Fcn+O7u6afXSKWdN" Content-Disposition: inline In-Reply-To: <201107220855.10774.jhb@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: freebsd-net@freebsd.org, rmacklem@freebsd.org, Jeremiah Lott Subject: Re: LOR with nfsclient "sillyrename" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jul 2011 13:12:06 -0000 --Fcn+O7u6afXSKWdN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 22, 2011 at 08:55:10AM -0400, John Baldwin wrote: > On Thursday, July 21, 2011 4:19:59 pm Jeremiah Lott wrote: > > We're seeing nfsclient deadlocks with what looks like lock order revers= al after removing a "silly rename". It is fairly rare, but we've seen it= =20 > happen a few times. I included relevant back traces from an occurrence. = From what I can see, nfs_inactive() is called with the vnode locked. If= =20 > there is a silly-rename, it will call vrele() on its parent directory, wh= ich can potentially try to lock the parent directory. Since this is the=20 > opposite order of the lock acquisition in lookup, it can deadlock. This = happened in a FreeBSD7 build, but I looked through freebsd head and=20 > didn't see any change that addressed this. Anyone seen this before? >=20 > I haven't seen this before, but your analysis looks correct to me. >=20 > Perhaps the best fix would be to defer the actual freeing of the sillyren= ame > to an asynchronous task? Maybe something like this (untested, uncompiled= ): >=20 > Index: nfsclient/nfsnode.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- nfsclient/nfsnode.h (revision 224254) > +++ nfsclient/nfsnode.h (working copy) > @@ -36,6 +36,7 @@ > #ifndef _NFSCLIENT_NFSNODE_H_ > #define _NFSCLIENT_NFSNODE_H_ > =20 > +#include > #if !defined(_NFSCLIENT_NFS_H_) && !defined(_KERNEL) > #include > #endif > @@ -45,8 +46,10 @@ > * can be removed by nfs_inactive() > */ > struct sillyrename { > + struct task s_task; > struct ucred *s_cred; > struct vnode *s_dvp; > + struct vnode *s_vp; > int (*s_removeit)(struct sillyrename *sp); > long s_namlen; > char s_name[32]; > Index: nfsclient/nfs_vnops.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- nfsclient/nfs_vnops.c (revision 224254) > +++ nfsclient/nfs_vnops.c (working copy) > @@ -1757,7 +1757,6 @@ > { > /* > * Make sure that the directory vnode is still valid. > - * XXX we should lock sp->s_dvp here. > */ > if (sp->s_dvp->v_type =3D=3D VBAD) > return (0); > @@ -2754,8 +2753,10 @@ > M_NFSREQ, M_WAITOK); > sp->s_cred =3D crhold(cnp->cn_cred); > sp->s_dvp =3D dvp; > + sp->s_vp =3D vp; > sp->s_removeit =3D nfs_removeit; > VREF(dvp); > + vhold(vp); > =20 > /*=20 > * Fudge together a funny name. > Index: nfsclient/nfs_node.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- nfsclient/nfs_node.c (revision 224254) > +++ nfsclient/nfs_node.c (working copy) > @@ -47,6 +47,7 @@ > #include > #include > #include > +#include > #include > =20 > #include > @@ -185,6 +186,26 @@ > return (0); > } > =20 > +static void > +nfs_freesillyrename(void *arg, int pending) > +{ > + struct sillyrename *sp; > + > + sp =3D arg; > + vn_lock(sp->s_dvp, LK_SHARED | LK_RETRY); I think taking an exclusive lock is somewhat more clean. > + vn_lock(sp->s_vp, LK_EXCLUSIVE | LK_RETRY); I believe that you have to verify that at least dvp is not doomed. Due to this, I propose to only move the vrele() call to taskqueue. > + (void)nfs_vinvalbuf(ap->a_vp, 0, td, 1); > + /* > + * Remove the silly file that was rename'd earlier > + */ > + (sp->s_removeit)(sp); > + crfree(sp->s_cred); > + vput(sp->s_dvp); > + VOP_UNLOCK(sp->s_vp, 0); > + vdrop(sp->s_vp); > + free((caddr_t)sp, M_NFSREQ); > +} > + > int > nfs_inactive(struct vop_inactive_args *ap) > { > @@ -200,15 +221,9 @@ > } else > sp =3D NULL; > if (sp) { > + TASK_INIT(&sp->task, 0, nfs_freesillyrename, sp); > + taskqueue_enqueue(taskqueue_thread, &sp->task); > mtx_unlock(&np->n_mtx); > - (void)nfs_vinvalbuf(ap->a_vp, 0, td, 1); > - /* > - * Remove the silly file that was rename'd earlier > - */ > - (sp->s_removeit)(sp); > - crfree(sp->s_cred); > - vrele(sp->s_dvp); > - free((caddr_t)sp, M_NFSREQ); > mtx_lock(&np->n_mtx); > } > np->n_flag &=3D NMODIFIED; >=20 > --=20 > John Baldwin > _______________________________________________ > 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" --Fcn+O7u6afXSKWdN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4pdx8ACgkQC3+MBN1Mb4gYwwCePg47CM8VYF1BG3zKgf3VPQ68 BnAAoOW3ff1Se7g+T3VgjdC+6zDGKRkY =pZXt -----END PGP SIGNATURE----- --Fcn+O7u6afXSKWdN-- From owner-freebsd-net@FreeBSD.ORG Fri Jul 22 13:15:27 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68E291065672 for ; Fri, 22 Jul 2011 13:15:27 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from mail-chaos.rambler.ru (mail-chaos.rambler.ru [81.19.68.130]) by mx1.freebsd.org (Postfix) with ESMTP id 27F3A8FC1B for ; Fri, 22 Jul 2011 13:15:26 +0000 (UTC) Received: from citrin.office.vega.ru (unknown [178.214.36.169]) (Authenticated sender: citrin@citrin.ru) by mail-chaos.rambler.ru (Postfix) with ESMTPSA id 6A5781702C for ; Fri, 22 Jul 2011 17:03:47 +0400 (MSD) Message-ID: <4E297533.4040109@citrin.ru> Date: Fri, 22 Jul 2011 17:03:47 +0400 From: Anton Yuzhaninov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110527 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: connections in CLOSED state X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jul 2011 13:15:27 -0000 It seems to be there is some race and/or leak in tcp stack: 1. Netstat show connections in closed state (for a long time): > netstat -n | egrep '(Proto|CLOSED)' Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 10.25.1.54.35543 10.25.1.54.35544 CLOSED tcp4 0 0 10.25.1.54.57273 10.25.1.54.57274 CLOSED tcp4 0 0 10.25.1.54.40445 10.25.1.54.62378 CLOSED tcp4 0 0 10.25.1.54.43403 10.25.1.54.43404 CLOSED tcp4 0 0 10.25.1.54.36380 10.25.1.54.36381 CLOSED ... 2. sockstat don't show any processes to which this sockets can belong to. some info from kgdb: > netstat -nA -p tcp | egrep '(Tcpcb|CLOSED)' Tcpcb Proto Recv-Q Send-Q Local Address Foreign Address (state) ffffff01abfb8370 tcp4 0 0 10.25.1.54.35543 10.25.1.54.35544 CLOSED (kgdb) set $t = (struct tcpcb) *0xffffff01abfb8370 (kgdb) p $t->t_inpcb->inp_socket->so_count $18 = 0 > uname -srp FreeBSD 8.2-PRERELEASE-20110101 amd64 -- Anton Yuzhaninov From owner-freebsd-net@FreeBSD.ORG Fri Jul 22 13:44: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 C80D91065742; Fri, 22 Jul 2011 13:44:43 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 413C48FC1F; Fri, 22 Jul 2011 13:44:42 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYAAIx9KU6DaFvO/2dsb2JhbABHDIRMky2QR7MpkQ+BK4F7LAKBXIEPBJJukHs X-IronPort-AV: E=Sophos;i="4.67,247,1309752000"; d="scan'208";a="131945797" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 22 Jul 2011 09:44:42 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 3CC2EB3F4D; Fri, 22 Jul 2011 09:44:42 -0400 (EDT) Date: Fri, 22 Jul 2011 09:44:42 -0400 (EDT) From: Rick Macklem To: Kostik Belousov Message-ID: <1600540075.883123.1311342282234.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110722131159.GR17489@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Jeremiah Lott , freebsd-net@freebsd.org, John Baldwin , rmacklem@freebsd.org Subject: Re: LOR with nfsclient "sillyrename" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jul 2011 13:44:43 -0000 Kostik Belousov wrote: > On Fri, Jul 22, 2011 at 08:55:10AM -0400, John Baldwin wrote: > > On Thursday, July 21, 2011 4:19:59 pm Jeremiah Lott wrote: > > > We're seeing nfsclient deadlocks with what looks like lock order > > > reversal after removing a "silly rename". It is fairly rare, but > > > we've seen it > > happen a few times. I included relevant back traces from an > > occurrence. From what I can see, nfs_inactive() is called with the > > vnode locked. If > > there is a silly-rename, it will call vrele() on its parent > > directory, which can potentially try to lock the parent directory. > > Since this is the > > opposite order of the lock acquisition in lookup, it can deadlock. > > This happened in a FreeBSD7 build, but I looked through freebsd head > > and > > didn't see any change that addressed this. Anyone seen this before? > > > > I haven't seen this before, but your analysis looks correct to me. > > > > Perhaps the best fix would be to defer the actual freeing of the > > sillyrename > > to an asynchronous task? Maybe something like this (untested, > > uncompiled): > > > > Index: nfsclient/nfsnode.h > > =================================================================== > > --- nfsclient/nfsnode.h (revision 224254) > > +++ nfsclient/nfsnode.h (working copy) > > @@ -36,6 +36,7 @@ > > #ifndef _NFSCLIENT_NFSNODE_H_ > > #define _NFSCLIENT_NFSNODE_H_ > > > > +#include > > #if !defined(_NFSCLIENT_NFS_H_) && !defined(_KERNEL) > > #include > > #endif > > @@ -45,8 +46,10 @@ > > * can be removed by nfs_inactive() > > */ > > struct sillyrename { > > + struct task s_task; > > struct ucred *s_cred; > > struct vnode *s_dvp; > > + struct vnode *s_vp; > > int (*s_removeit)(struct sillyrename *sp); > > long s_namlen; > > char s_name[32]; > > Index: nfsclient/nfs_vnops.c > > =================================================================== > > --- nfsclient/nfs_vnops.c (revision 224254) > > +++ nfsclient/nfs_vnops.c (working copy) > > @@ -1757,7 +1757,6 @@ > > { > > /* > > * Make sure that the directory vnode is still valid. > > - * XXX we should lock sp->s_dvp here. > > */ > > if (sp->s_dvp->v_type == VBAD) > > return (0); > > @@ -2754,8 +2753,10 @@ > > M_NFSREQ, M_WAITOK); > > sp->s_cred = crhold(cnp->cn_cred); > > sp->s_dvp = dvp; > > + sp->s_vp = vp; > > sp->s_removeit = nfs_removeit; > > VREF(dvp); > > + vhold(vp); > > > > /* > > * Fudge together a funny name. > > Index: nfsclient/nfs_node.c > > =================================================================== > > --- nfsclient/nfs_node.c (revision 224254) > > +++ nfsclient/nfs_node.c (working copy) > > @@ -47,6 +47,7 @@ > > #include > > #include > > #include > > +#include > > #include > > > > #include > > @@ -185,6 +186,26 @@ > > return (0); > > } > > > > +static void > > +nfs_freesillyrename(void *arg, int pending) > > +{ > > + struct sillyrename *sp; > > + > > + sp = arg; > > + vn_lock(sp->s_dvp, LK_SHARED | LK_RETRY); > I think taking an exclusive lock is somewhat more clean. > > + vn_lock(sp->s_vp, LK_EXCLUSIVE | LK_RETRY); > I believe that you have to verify that at least dvp is not doomed. > > Due to this, I propose to only move the vrele() call to taskqueue. Yes. I was thinking that it would be simpler (and I'm a chicken about changing more than I have to for these kinds of things:-) to juts defer the vrele(). I wasn't sure that holding onto "vp" when it was being recycled was such a good plan, although I'm not saying it would actually break anything. (As I understand it, VOP_INACTIVE() sometimes gets delayed until just before VOP_RECLAIM() and doing a VHOLD(vp) in there just seems like it's asking for trouble?;-) I'll post with a patch, once I've tested something. > > + (void)nfs_vinvalbuf(ap->a_vp, 0, td, 1); > > + /* > > + * Remove the silly file that was rename'd earlier > > + */ > > + (sp->s_removeit)(sp); > > + crfree(sp->s_cred); > > + vput(sp->s_dvp); > > + VOP_UNLOCK(sp->s_vp, 0); > > + vdrop(sp->s_vp); > > + free((caddr_t)sp, M_NFSREQ); > > +} > > + > > int > > nfs_inactive(struct vop_inactive_args *ap) > > { > > @@ -200,15 +221,9 @@ > > } else > > sp = NULL; > > if (sp) { > > + TASK_INIT(&sp->task, 0, nfs_freesillyrename, sp); > > + taskqueue_enqueue(taskqueue_thread, &sp->task); > > mtx_unlock(&np->n_mtx); > > - (void)nfs_vinvalbuf(ap->a_vp, 0, td, 1); > > - /* > > - * Remove the silly file that was rename'd earlier > > - */ > > - (sp->s_removeit)(sp); > > - crfree(sp->s_cred); > > - vrele(sp->s_dvp); > > - free((caddr_t)sp, M_NFSREQ); > > mtx_lock(&np->n_mtx); > > } > > np->n_flag &= NMODIFIED; > > Thanks everyone, for the helpful suggestions, rick From owner-freebsd-net@FreeBSD.ORG Fri Jul 22 14:07: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 3BF25106566C; Fri, 22 Jul 2011 14:07:06 +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 EEC888FC0A; Fri, 22 Jul 2011 14:07:05 +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 71E4546B24; Fri, 22 Jul 2011 10:07:05 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0C9968A02C; Fri, 22 Jul 2011 10:07:05 -0400 (EDT) From: John Baldwin To: Kostik Belousov Date: Fri, 22 Jul 2011 10:02:23 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <44626428-CF14-4B20-AB57-6D4E8F4678AE@averesystems.com> <201107220855.10774.jhb@freebsd.org> <20110722131159.GR17489@deviant.kiev.zoral.com.ua> In-Reply-To: <20110722131159.GR17489@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201107221002.23554.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 22 Jul 2011 10:07:05 -0400 (EDT) Cc: freebsd-net@freebsd.org, rmacklem@freebsd.org, Jeremiah Lott Subject: Re: LOR with nfsclient "sillyrename" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jul 2011 14:07:06 -0000 On Friday, July 22, 2011 9:11:59 am Kostik Belousov wrote: > On Fri, Jul 22, 2011 at 08:55:10AM -0400, John Baldwin wrote: > > On Thursday, July 21, 2011 4:19:59 pm Jeremiah Lott wrote: > > > We're seeing nfsclient deadlocks with what looks like lock order reversal after removing a "silly rename". It is fairly rare, but we've seen it > > happen a few times. I included relevant back traces from an occurrence. From what I can see, nfs_inactive() is called with the vnode locked. If > > there is a silly-rename, it will call vrele() on its parent directory, which can potentially try to lock the parent directory. Since this is the > > opposite order of the lock acquisition in lookup, it can deadlock. This happened in a FreeBSD7 build, but I looked through freebsd head and > > didn't see any change that addressed this. Anyone seen this before? > > > > I haven't seen this before, but your analysis looks correct to me. > > > > Perhaps the best fix would be to defer the actual freeing of the sillyrename > > to an asynchronous task? Maybe something like this (untested, uncompiled): > > > > Index: nfsclient/nfsnode.h > > =================================================================== > > --- nfsclient/nfsnode.h (revision 224254) > > +++ nfsclient/nfsnode.h (working copy) > > @@ -36,6 +36,7 @@ > > #ifndef _NFSCLIENT_NFSNODE_H_ > > #define _NFSCLIENT_NFSNODE_H_ > > > > +#include > > #if !defined(_NFSCLIENT_NFS_H_) && !defined(_KERNEL) > > #include > > #endif > > @@ -45,8 +46,10 @@ > > * can be removed by nfs_inactive() > > */ > > struct sillyrename { > > + struct task s_task; > > struct ucred *s_cred; > > struct vnode *s_dvp; > > + struct vnode *s_vp; > > int (*s_removeit)(struct sillyrename *sp); > > long s_namlen; > > char s_name[32]; > > Index: nfsclient/nfs_vnops.c > > =================================================================== > > --- nfsclient/nfs_vnops.c (revision 224254) > > +++ nfsclient/nfs_vnops.c (working copy) > > @@ -1757,7 +1757,6 @@ > > { > > /* > > * Make sure that the directory vnode is still valid. > > - * XXX we should lock sp->s_dvp here. > > */ > > if (sp->s_dvp->v_type == VBAD) > > return (0); > > @@ -2754,8 +2753,10 @@ > > M_NFSREQ, M_WAITOK); > > sp->s_cred = crhold(cnp->cn_cred); > > sp->s_dvp = dvp; > > + sp->s_vp = vp; > > sp->s_removeit = nfs_removeit; > > VREF(dvp); > > + vhold(vp); > > > > /* > > * Fudge together a funny name. > > Index: nfsclient/nfs_node.c > > =================================================================== > > --- nfsclient/nfs_node.c (revision 224254) > > +++ nfsclient/nfs_node.c (working copy) > > @@ -47,6 +47,7 @@ > > #include > > #include > > #include > > +#include > > #include > > > > #include > > @@ -185,6 +186,26 @@ > > return (0); > > } > > > > +static void > > +nfs_freesillyrename(void *arg, int pending) > > +{ > > + struct sillyrename *sp; > > + > > + sp = arg; > > + vn_lock(sp->s_dvp, LK_SHARED | LK_RETRY); > I think taking an exclusive lock is somewhat more clean. > > + vn_lock(sp->s_vp, LK_EXCLUSIVE | LK_RETRY); > I believe that you have to verify that at least dvp is not doomed. > > Due to this, I propose to only move the vrele() call to taskqueue. Fair enough. It might have been nice to fix the XXX in nfs_removeit() where it checks the dvp for VBAD without a lock. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Jul 22 15:08:20 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CB7E106564A for ; Fri, 22 Jul 2011 15:08:20 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id DAFF28FC0C for ; Fri, 22 Jul 2011 15:08:19 +0000 (UTC) Received: by ewy1 with SMTP id 1so2406876ewy.13 for ; Fri, 22 Jul 2011 08:08:18 -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=NA8AIitbVkaCFpMFPy9zaVdeRJQ77fWhLVqHNCwdqLY=; b=bBjNDiWVXibzFMRt6Pw+dfRxSZkwzNZhwyPQHbjT17To2ZfctZQqZ45zMUkk9kE+oH 5ybQkcFMSv7kulMCLibs23KWISR6XWXrV6jjdkjD0uPOF7GyIaagICJCO0eWuoqgAGt1 fY5xsG9fgK6hPCWKozVrOql+1OQ4wIjzU+Z8o= MIME-Version: 1.0 Received: by 10.213.13.19 with SMTP id z19mr728079ebz.107.1311347298561; Fri, 22 Jul 2011 08:08:18 -0700 (PDT) Received: by 10.213.31.194 with HTTP; Fri, 22 Jul 2011 08:08:18 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Jul 2011 11:08:18 -0400 Message-ID: From: Ryan Stone To: Ivan Alexandrovich Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: Ethernet link status on i82576 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jul 2011 15:08:20 -0000 I notice that the interface not up in your test. If you ifconfig it up does it detect that it has lost link? The driver isn't really running anymore when you bring the link down -- interrupts are disabled, for example, so it will never get a link down interrupt. From owner-freebsd-net@FreeBSD.ORG Fri Jul 22 16:32:05 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3106B1065672 for ; Fri, 22 Jul 2011 16:32:05 +0000 (UTC) (envelope-from jfvogel@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 D857C8FC19 for ; Fri, 22 Jul 2011 16:32:04 +0000 (UTC) Received: by vws18 with SMTP id 18so2391313vws.13 for ; Fri, 22 Jul 2011 09:32:04 -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=wGnwQeyr8b+vqxJ7dNrmSrBc9M4O0Gij1MzZC2nBLsk=; b=JE1bA/cZaqtijoFRiUNRFzsE/5utnKimDdgtbBjZwTo5godyysKasnT1HuPiGRSZaC RBMhJ4+4mgJwPxmPMjD11UMPZZH+R2kDCCcfNstV7dyq0X9zOfksjdDK35jEs5Nfg1To z13Ieh+9Gl46410+oLunBvAYdgjFg72Znh3kI= MIME-Version: 1.0 Received: by 10.52.175.229 with SMTP id cd5mr1865209vdc.197.1311352324127; Fri, 22 Jul 2011 09:32:04 -0700 (PDT) Received: by 10.52.187.66 with HTTP; Fri, 22 Jul 2011 09:32:04 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Jul 2011 09:32:04 -0700 Message-ID: From: Jack Vogel To: Ryan Stone Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Ivan Alexandrovich Subject: Re: Ethernet link status on i82576 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jul 2011 16:32:05 -0000 Correct, until you up the interface there are no interrupts enabled so you don't detect link change. Not a bug, linux is a different kettle of fish... Jack On Fri, Jul 22, 2011 at 8:08 AM, Ryan Stone wrote: > I notice that the interface not up in your test. If you ifconfig it > up does it detect that it has lost link? The driver isn't really > running anymore when you bring the link down -- interrupts are > disabled, for example, so it will never get a link down interrupt. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Jul 22 16:50:12 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 49794106564A for ; Fri, 22 Jul 2011 16:50:12 +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 376DE8FC08 for ; Fri, 22 Jul 2011 16:50:12 +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 p6MGoC5Z034676 for ; Fri, 22 Jul 2011 16:50:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6MGoCcH034675; Fri, 22 Jul 2011 16:50:12 GMT (envelope-from gnats) Date: Fri, 22 Jul 2011 16:50:12 GMT Message-Id: <201107221650.p6MGoCcH034675@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: bin/150642: 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: Fri, 22 Jul 2011 16:50:12 -0000 The following reply was made to PR bin/150642; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: bin/150642: commit references a PR Date: Fri, 22 Jul 2011 16:42:26 +0000 (UTC) Author: tuexen Date: Fri Jul 22 16:42:12 2011 New Revision: 224271 URL: http://svn.freebsd.org/changeset/base/224271 Log: Fix the following bugs related to the SCTP support of netstat: * Correctly handle -a. * -A isn't supported. * Show all closed 1-to-1 and 1-to-many style sockets. * Show all listening 1-to-many style sockets. * Use consistent formatting for -W. PR: 150642 Approved by: re@ MFC after: 4 weeks. Modified: head/usr.bin/netstat/sctp.c Modified: head/usr.bin/netstat/sctp.c ============================================================================== --- head/usr.bin/netstat/sctp.c Fri Jul 22 16:37:04 2011 (r224270) +++ head/usr.bin/netstat/sctp.c Fri Jul 22 16:42:12 2011 (r224271) @@ -1,5 +1,6 @@ /*- * Copyright (c) 2001-2007, by Weongyo Jeong. All rights reserved. + * Copyright (c) 2011, by Michael Tuexen. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions are met: @@ -63,7 +64,6 @@ __FBSDID("$FreeBSD$"); #ifdef SCTP -void inetprint(struct in_addr *, int, const char *, int); static void sctp_statesprint(uint32_t state); #define NETSTAT_SCTP_STATES_CLOSED 0x0 @@ -102,6 +102,124 @@ struct xraddr_entry { LIST_ENTRY(xraddr_entry) xraddr_entries; }; +/* + * Construct an Internet address representation. + * If numeric_addr has been supplied, give + * numeric value, otherwise try for symbolic name. + */ +static char * +inetname(struct in_addr *inp) +{ + char *cp; + static char line[MAXHOSTNAMELEN]; + struct hostent *hp; + struct netent *np; + + cp = 0; + if (!numeric_addr && inp->s_addr != INADDR_ANY) { + int net = inet_netof(*inp); + int lna = inet_lnaof(*inp); + + if (lna == INADDR_ANY) { + np = getnetbyaddr(net, AF_INET); + if (np) + cp = np->n_name; + } + if (cp == 0) { + hp = gethostbyaddr((char *)inp, sizeof (*inp), AF_INET); + if (hp) { + cp = hp->h_name; + trimdomain(cp, strlen(cp)); + } + } + } + if (inp->s_addr == INADDR_ANY) + strcpy(line, "*"); + else if (cp) { + strlcpy(line, cp, sizeof(line)); + } else { + inp->s_addr = ntohl(inp->s_addr); +#define C(x) ((u_int)((x) & 0xff)) + sprintf(line, "%u.%u.%u.%u", C(inp->s_addr >> 24), + C(inp->s_addr >> 16), C(inp->s_addr >> 8), C(inp->s_addr)); + inp->s_addr = htonl(inp->s_addr); + } + return (line); +} + +#ifdef INET6 +static char ntop_buf[INET6_ADDRSTRLEN]; + +static char * +inet6name(struct in6_addr *in6p) +{ + char *cp; + static char line[50]; + struct hostent *hp; + static char domain[MAXHOSTNAMELEN]; + static int first = 1; + + if (first && !numeric_addr) { + first = 0; + if (gethostname(domain, MAXHOSTNAMELEN) == 0 && + (cp = index(domain, '.'))) + (void) strcpy(domain, cp + 1); + else + domain[0] = 0; + } + cp = 0; + if (!numeric_addr && !IN6_IS_ADDR_UNSPECIFIED(in6p)) { + hp = gethostbyaddr((char *)in6p, sizeof(*in6p), AF_INET6); + if (hp) { + if ((cp = index(hp->h_name, '.')) && + !strcmp(cp + 1, domain)) + *cp = 0; + cp = hp->h_name; + } + } + if (IN6_IS_ADDR_UNSPECIFIED(in6p)) + strcpy(line, "*"); + else if (cp) + strcpy(line, cp); + else + sprintf(line, "%s", + inet_ntop(AF_INET6, (void *)in6p, ntop_buf, + sizeof(ntop_buf))); + return (line); +} +#endif + +static void +sctp_print_address(union sctp_sockstore *address, int port, int num_port) +{ + struct servent *sp = 0; + char line[80], *cp; + int width; + + switch (address->sa.sa_family) { + case AF_INET: + sprintf(line, "%.*s.", Wflag ? 39 : 16, inetname(&address->sin.sin_addr)); + break; +#ifdef INET6 + case AF_INET6: + sprintf(line, "%.*s.", Wflag ? 39 : 16, inet6name(&address->sin6.sin6_addr)); + break; +#endif + default: + sprintf(line, "%.*s.", Wflag ? 39 : 16, ""); + break; + } + cp = index(line, '\0'); + if (!num_port && port) + sp = getservbyport((int)port, "sctp"); + if (sp || port == 0) + sprintf(cp, "%.15s ", sp ? sp->s_name : "*"); + else + sprintf(cp, "%d ", ntohs((u_short)port)); + width = Wflag ? 45 : 22; + printf("%-*.*s ", width, width, line); +} + static int sctp_skip_xinpcb_ifneed(char *buf, const size_t buflen, size_t *offset) { @@ -150,18 +268,14 @@ sctp_skip_xinpcb_ifneed(char *buf, const } static void -sctp_process_tcb(struct xsctp_tcb *xstcb, const char *name, +sctp_process_tcb(struct xsctp_tcb *xstcb, char *buf, const size_t buflen, size_t *offset, int *indent) { int i, xl_total = 0, xr_total = 0, x_max; - struct sockaddr *sa; struct xsctp_raddr *xraddr; struct xsctp_laddr *xladdr; struct xladdr_entry *prev_xl = NULL, *xl = NULL, *xl_tmp; struct xraddr_entry *prev_xr = NULL, *xr = NULL, *xr_tmp; -#ifdef INET6 - struct sockaddr_in6 *in6; -#endif LIST_INIT(&xladdr_head); LIST_INIT(&xraddr_head); @@ -220,38 +334,22 @@ sctp_process_tcb(struct xsctp_tcb *xstcb x_max = (xl_total > xr_total) ? xl_total : xr_total; for (i = 0; i < x_max; i++) { if (((*indent == 0) && i > 0) || *indent > 0) - printf("%-11s ", " "); + printf("%-12s ", " "); if (xl != NULL) { - sa = &(xl->xladdr->address.sa); - if ((sa->sa_family) == AF_INET) - inetprint(&((struct sockaddr_in *)sa)->sin_addr, - htons(xstcb->local_port), - name, numeric_port); -#ifdef INET6 - else { - in6 = (struct sockaddr_in6 *)sa; - inet6print(&in6->sin6_addr, - htons(xstcb->local_port), - name, numeric_port); + sctp_print_address(&(xl->xladdr->address), + htons(xstcb->local_port), numeric_port); + } else { + if (Wflag) { + printf("%-45s ", " "); + } else { + printf("%-22s ", " "); } -#endif } if (xr != NULL && !Lflag) { - sa = &(xr->xraddr->address.sa); - if ((sa->sa_family) == AF_INET) - inetprint(&((struct sockaddr_in *)sa)->sin_addr, - htons(xstcb->remote_port), - name, numeric_port); -#ifdef INET6 - else { - in6 = (struct sockaddr_in6 *)sa; - inet6print(&in6->sin6_addr, - htons(xstcb->remote_port), - name, numeric_port); - } -#endif + sctp_print_address(&(xr->xraddr->address), + htons(xstcb->remote_port), numeric_port); } if (xl != NULL) @@ -285,53 +383,21 @@ out: } } -#ifdef SCTP_DEBUG -uint32_t sctp_pdup[64]; -int sctp_pcnt = 0; -#endif - static void -sctp_process_inpcb(struct xsctp_inpcb *xinpcb, const char *name, +sctp_process_inpcb(struct xsctp_inpcb *xinpcb, char *buf, const size_t buflen, size_t *offset) { - int offset_backup, indent = 0, xladdr_total = 0, is_listening = 0; + int indent = 0, xladdr_total = 0, is_listening = 0; static int first = 1; - char *tname; + char *tname, *pname; struct xsctp_tcb *xstcb; struct xsctp_laddr *xladdr; - struct sockaddr *sa; -#ifdef INET6 - struct sockaddr_in6 *in6; -#endif + size_t offset_laddr; + int process_closed; - if ((xinpcb->flags & SCTP_PCB_FLAGS_TCPTYPE) == - SCTP_PCB_FLAGS_TCPTYPE && xinpcb->maxqlen > 0) + if (xinpcb->maxqlen > 0) is_listening = 1; - if (!Lflag && !is_listening && - !(xinpcb->flags & SCTP_PCB_FLAGS_CONNECTED)) { -#ifdef SCTP_DEBUG - int i, found = 0; - - for (i = 0; i < sctp_pcnt; i++) { - if (sctp_pdup[i] == xinpcb->flags) { - found = 1; - break; - } - } - if (!found) { - sctp_pdup[sctp_pcnt++] = xinpcb->flags; - if (sctp_pcnt >= 64) - sctp_pcnt = 0; - printf("[0x%08x]", xinpcb->flags); - } -#endif - offset_backup = *offset; - if (!sctp_skip_xinpcb_ifneed(buf, buflen, offset)) - return; - *offset = offset_backup; - } - if (first) { if (!Lflag) { printf("Active SCTP associations"); @@ -340,90 +406,115 @@ sctp_process_inpcb(struct xsctp_inpcb *x } else printf("Current listen queue sizes (qlen/maxqlen)"); putchar('\n'); - if (Aflag) - printf("%-8.8s ", "Socket"); if (Lflag) - printf("%-5.5s %-5.5s %-8.8s %-22.22s\n", + printf("%-6.6s %-5.5s %-8.8s %-22.22s\n", "Proto", "Type", "Listen", "Local Address"); else - printf((Aflag && !Wflag) ? - "%-5.5s %-5.5s %-18.18s %-18.18s %s\n" : - "%-5.5s %-5.5s %-22.22s %-22.22s %s\n", - "Proto", "Type", - "Local Address", "Foreign Address", - "(state)"); + if (Wflag) + printf("%-6.6s %-5.5s %-45.45s %-45.45s %s\n", + "Proto", "Type", + "Local Address", "Foreign Address", + "(state)"); + else + printf("%-6.6s %-5.5s %-22.22s %-22.22s %s\n", + "Proto", "Type", + "Local Address", "Foreign Address", + "(state)"); first = 0; } - if (Lflag && xinpcb->maxqlen == 0) { + xladdr = (struct xsctp_laddr *)(buf + *offset); + if (Lflag && !is_listening) { sctp_skip_xinpcb_ifneed(buf, buflen, offset); return; } - if (Aflag) - printf("%8lx ", (u_long)xinpcb); - printf("%-5.5s ", name); + if (xinpcb->flags & SCTP_PCB_FLAGS_BOUND_V6) { + /* Can't distinguish between sctp46 and sctp6 */ + pname = "sctp46"; + } else { + pname = "sctp4"; + } if (xinpcb->flags & SCTP_PCB_FLAGS_TCPTYPE) tname = "1to1"; else if (xinpcb->flags & SCTP_PCB_FLAGS_UDPTYPE) tname = "1toN"; else - return; - - printf("%-5.5s ", tname); + tname = "????"; if (Lflag) { char buf1[9]; snprintf(buf1, 9, "%hu/%hu", xinpcb->qlen, xinpcb->maxqlen); + printf("%-6.6s %-5.5s ", pname, tname); printf("%-8.8s ", buf1); } - /* - * process the local address. This routine are used for Lflag. - */ + + offset_laddr = *offset; + process_closed = 0; +retry: while (*offset < buflen) { xladdr = (struct xsctp_laddr *)(buf + *offset); *offset += sizeof(struct xsctp_laddr); - if (xladdr->last == 1) + if (xladdr->last) { + if (aflag && !Lflag && (xladdr_total == 0) && process_closed) { + printf("%-6.6s %-5.5s ", pname, tname); + if (Wflag) { + printf("%-91.91s CLOSED", " "); + } else { + printf("%-45.45s CLOSED", " "); + } + } + if (process_closed || is_listening) { + putchar('\n'); + } break; + } - if (!Lflag && !is_listening) + if (!Lflag && !is_listening && !process_closed) continue; - if (xladdr_total != 0) + if (xladdr_total == 0) { + printf("%-6.6s %-5.5s ", pname, tname); + } else { putchar('\n'); - if (xladdr_total > 0) printf((Lflag) ? - "%-20.20s " : "%-11.11s ", " "); - - sa = &(xladdr->address.sa); - if ((sa->sa_family) == AF_INET) - inetprint(&((struct sockaddr_in *)sa)->sin_addr, - htons(xinpcb->local_port), name, numeric_port); -#ifdef INET6 - else { - in6 = (struct sockaddr_in6 *)sa; - inet6print(&in6->sin6_addr, - htons(xinpcb->local_port), name, numeric_port); + "%-21.21s " : "%-12.12s ", " "); + } + sctp_print_address(&(xladdr->address), + htons(xinpcb->local_port), numeric_port); + if (aflag && !Lflag && xladdr_total == 0) { + if (Wflag) { + if (process_closed) { + printf("%-45.45s CLOSED", " "); + } else { + printf("%-45.45s LISTEN", " "); + } + } else { + if (process_closed) { + printf("%-22.22s CLOSED", " "); + } else { + printf("%-22.22s LISTEN", " "); + } + } } -#endif - - if (!Lflag && xladdr_total == 0 && is_listening == 1) - printf("%-22.22s LISTEN", " "); - xladdr_total++; } xstcb = (struct xsctp_tcb *)(buf + *offset); *offset += sizeof(struct xsctp_tcb); + if (aflag && (xladdr_total == 0) && xstcb->last && !process_closed) { + process_closed = 1; + *offset = offset_laddr; + goto retry; + } while (xstcb->last == 0 && *offset < buflen) { - sctp_process_tcb(xstcb, name, buf, buflen, offset, &indent); + printf("%-6.6s %-5.5s ", pname, tname); + sctp_process_tcb(xstcb, buf, buflen, offset, &indent); indent++; xstcb = (struct xsctp_tcb *)(buf + *offset); *offset += sizeof(struct xsctp_tcb); } - - putchar('\n'); } /* @@ -461,7 +552,7 @@ sctp_protopr(u_long off __unused, xinpcb = (struct xsctp_inpcb *)(buf + offset); offset += sizeof(struct xsctp_inpcb); while (xinpcb->last == 0 && offset < len) { - sctp_process_inpcb(xinpcb, name, buf, (const size_t)len, + sctp_process_inpcb(xinpcb, buf, (const size_t)len, &offset); xinpcb = (struct xsctp_inpcb *)(buf + offset); _______________________________________________ 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 Fri Jul 22 18:03: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 B1091106567C for ; Fri, 22 Jul 2011 18:03:40 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 981FF8FC0A for ; Fri, 22 Jul 2011 18:03:40 +0000 (UTC) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 6D5209891; Fri, 22 Jul 2011 11:03:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1311357820; bh=lkod5xTg6tx0sjephMk4aPLIdUnqtQC2hao0eqOWzio=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=xdK4IXtIp+SMdkF9nIda1+zlBip0T7Q45wh6sB3fd6ritm7Hy4K/vErBnhLgqNhHK n086C7FbalUqY5F2fGzeFF05C1+Jdf3Eqi3+8Fem8kLlmS5J9EyN5MN1BIf9FzG+Me wQ/im5P40IgLZT0tnugDyLP1Y0Nc+AtujhUjJWOo= Message-ID: <4E29BB7B.5000704@delphij.net> Date: Fri, 22 Jul 2011 11:03:39 -0700 From: Xin LI Organization: The FreeBSD Project MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4E284D09.9060308@ukr.net> In-Reply-To: <4E284D09.9060308@ukr.net> OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: I want to change the ToS / DSCP on FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 18:03:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/21/11 09:00, Vladislav V. Prodan wrote: > Or until just after ng_patch(4)? > > Inspired by the use of the Yahoo-balancing traffic > http://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk45.nanog51-Schaumann.pdf I > think they did released the code under 3 clause BSD license. https://github.com/yahoo/l3dsr/tree/master/ We should probably make a port or import it into the base system, I think? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBCAAGBQJOKbt7AAoJEATO+BI/yjfBQPwIAME0A4DCa6zO21Qz2noZ0RxW TQV6v6sMbpfmW4Y4l7Qw7UTyd++A7nClSweeDTp3Raws/hmYL+TSYRGUK8qf5lsz GAG9S6SFHnHVPVc3Wv4JaPrEVrtozZE+I/Z1ZP9fgcbXFWSYhuG2kuDtyGS8o0R9 aOE7iNgDCibLqS2byIKG6etp3aRNlEiQqdotd75lhPcNY7cWXLAdT5v/LYN7vvxZ kQNWFXR3y9P7GRJ2dn0DzbheMs9KAYbtY2px6wtXrVc2WF6CoZVXoFospsCJv4KF 2BjNgpxjjmn1ZttS5WmQeRZKsFVL8KYeRBe+Wl1KwNxo9+dZvu0KhyIrDB1nPH4= =aqia -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Fri Jul 22 19:42:27 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46EB4106566C for ; Fri, 22 Jul 2011 19:42:27 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 1F8478FC14 for ; Fri, 22 Jul 2011 19:42:26 +0000 (UTC) Received: by pzk5 with SMTP id 5so12169882pzk.17 for ; Fri, 22 Jul 2011 12:42:26 -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:content-transfer-encoding; bh=QjHzYptCOEDVyonqe/PBKkFedQ5B+uYG96jy0ymmy1U=; b=wqstfn/tIEbVGJiH9yRxutfk/hHT+jumhLSAdb6RAZk81mZqUnchdMQ5EQOfHVwKWK 6y0w0yZRRc+T36hMjaN5/Q+Qs9WNuRmCsmNKXGMnmy/cCEBWZkyGhIzYdsHI6wp9sPlw 30kbAcItmm1jqxB6gS1AcKO6/gPe68ZX7fe9s= MIME-Version: 1.0 Received: by 10.68.16.197 with SMTP id i5mr2855169pbd.410.1311363746533; Fri, 22 Jul 2011 12:42:26 -0700 (PDT) Received: by 10.68.56.8 with HTTP; Fri, 22 Jul 2011 12:42:26 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Jul 2011 15:42:26 -0400 Message-ID: From: Arnaud Lacombe To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Ivan Alexandrovich , Ryan Stone Subject: Re: Ethernet link status on i82576 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jul 2011 19:42:27 -0000 Hi, On Fri, Jul 22, 2011 at 12:32 PM, Jack Vogel wrote: > Correct, until you up the interface there are no interrupts enabled so yo= u > don't detect link change. > > Not a bug, linux is a different kettle of fish... > As we speak about this. Is there a reason for em(4) to have a soft-check in em_handle_link() to only update the link status if IFF_DRV_RUNNING is set ? If so, what is it ? Thanks, - Arnaud > Jack > > > On Fri, Jul 22, 2011 at 8:08 AM, Ryan Stone wrote: > >> I notice that the interface not up in your test. =A0If you ifconfig it >> up does it detect that it has lost link? =A0The driver isn't really >> running anymore when you bring the link down -- interrupts are >> disabled, for example, so it will never get a link down interrupt. >> _______________________________________________ >> 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" >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Jul 22 20:24:44 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 4B3A4106566B; Fri, 22 Jul 2011 20:24:44 +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 23B488FC15; Fri, 22 Jul 2011 20:24:44 +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 p6MKOig8032056; Fri, 22 Jul 2011 20:24:44 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6MKOiXV032052; Fri, 22 Jul 2011 20:24:44 GMT (envelope-from linimon) Date: Fri, 22 Jul 2011 20:24:44 GMT Message-Id: <201107222024.p6MKOiXV032052@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/159116: [sk] New D-Link DGE-530T revision not supported by sk(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jul 2011 20:24:44 -0000 Old Synopsis: New D-Link DGE-530T revision not supported by sk(4) New Synopsis: [sk] New D-Link DGE-530T revision not supported by sk(4) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jul 22 20:24:10 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=159116 From owner-freebsd-net@FreeBSD.ORG Fri Jul 22 20:49: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 A4834106566C; Fri, 22 Jul 2011 20:49:01 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7C8728FC18; Fri, 22 Jul 2011 20:49: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 p6MKn1g8051854; Fri, 22 Jul 2011 20:49:01 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6MKmx8B051846; Fri, 22 Jul 2011 20:48:59 GMT (envelope-from yongari) Date: Fri, 22 Jul 2011 20:48:59 GMT Message-Id: <201107222048.p6MKmx8B051846@freefall.freebsd.org> To: rob@ipninja.net, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/159116: [sk] New D-Link DGE-530T revision not supported by sk(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jul 2011 20:49:01 -0000 Synopsis: [sk] New D-Link DGE-530T revision not supported by sk(4) State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Fri Jul 22 20:46:35 UTC 2011 State-Changed-Why: Please apply patch at the following URL and rebuild your kernel. http://people.freebsd.org/~yongari/sk/sk.dge530.diff Let me know it goes on your box. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Fri Jul 22 20:46:35 UTC 2011 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=159116 From owner-freebsd-net@FreeBSD.ORG Fri Jul 22 21:11:27 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7518C106568F; Fri, 22 Jul 2011 21:11:27 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id E08028FC17; Fri, 22 Jul 2011 21:11:26 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAAfnKU6DaFvO/2dsb2JhbABHDBuEMaN3iQCqbZB+gyaCCoEPBJJukHs X-IronPort-AV: E=Sophos;i="4.67,249,1309752000"; d="scan'208";a="132000631" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 22 Jul 2011 17:11:26 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 26610B3E95; Fri, 22 Jul 2011 17:11:26 -0400 (EDT) Date: Fri, 22 Jul 2011 17:11:26 -0400 (EDT) From: Rick Macklem To: Jeremiah Lott Message-ID: <1931983408.909766.1311369086133.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <44626428-CF14-4B20-AB57-6D4E8F4678AE@averesystems.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_909765_1893841085.1311369086132" X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-net@freebsd.org, kib@freebsd.org, John Baldwin Subject: Re: LOR with nfsclient "sillyrename" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jul 2011 21:11:27 -0000 ------=_Part_909765_1893841085.1311369086132 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Jeremiah Lott wrote: > We're seeing nfsclient deadlocks with what looks like lock order > reversal after removing a "silly rename". It is fairly rare, but we've > seen it happen a few times. I included relevant back traces from an > occurrence. From what I can see, nfs_inactive() is called with the > vnode locked. If there is a silly-rename, it will call vrele() on its > parent directory, which can potentially try to lock the parent > directory. Since this is the opposite order of the lock acquisition in > lookup, it can deadlock. This happened in a FreeBSD7 build, but I > looked through freebsd head and didn't see any change that addressed > this. Anyone seen this before? > > Jeremiah Lott > Avere Systems > Please try the attached patch (which is also at): http://people.freebsd.org/~rmacklem/oldsilly.patch http://people.freebsd.org/~rmacklem/newsilly.patch (for the old and new clients in -current, respectively) - I think oldsilly.patch should apply to the 7.n kernel sources, although you might have to do the edit by hand? The patch is based on what jhb@ posted, with changes as recommended by kib@. Please let me know how testing goes with it, rick ps: Kostik, could you please review this, thanks. ------=_Part_909765_1893841085.1311369086132 Content-Type: text/x-patch; name=oldsilly.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=oldsilly.patch LS0tIG5mc2NsaWVudC9uZnNub2RlLmguc2F2CTIwMTEtMDctMjIgMTU6MzE6MTEuMDAwMDAwMDAw IC0wNDAwCisrKyBuZnNjbGllbnQvbmZzbm9kZS5oCTIwMTEtMDctMjIgMTU6MzI6NTQuMDAwMDAw MDAwIC0wNDAwCkBAIC0zNiw2ICszNiw3IEBACiAjaWZuZGVmIF9ORlNDTElFTlRfTkZTTk9ERV9I XwogI2RlZmluZSBfTkZTQ0xJRU5UX05GU05PREVfSF8KIAorI2luY2x1ZGUgPHN5cy9fdGFzay5o PgogI2lmICFkZWZpbmVkKF9ORlNDTElFTlRfTkZTX0hfKSAmJiAhZGVmaW5lZChfS0VSTkVMKQog I2luY2x1ZGUgPG5mcy9uZnMuaD4KICNlbmRpZgpAQCAtNDUsNiArNDYsNyBAQAogICogY2FuIGJl IHJlbW92ZWQgYnkgbmZzX2luYWN0aXZlKCkKICAqLwogc3RydWN0IHNpbGx5cmVuYW1lIHsKKwlz dHJ1Y3QJdGFzayBzX3Rhc2s7CiAJc3RydWN0CXVjcmVkICpzX2NyZWQ7CiAJc3RydWN0CXZub2Rl ICpzX2R2cDsKIAlpbnQJKCpzX3JlbW92ZWl0KShzdHJ1Y3Qgc2lsbHlyZW5hbWUgKnNwKTsKLS0t IG5mc2NsaWVudC9uZnNfbm9kZS5jLnNhdgkyMDExLTA3LTIyIDE1OjMzOjA0LjAwMDAwMDAwMCAt MDQwMAorKysgbmZzY2xpZW50L25mc19ub2RlLmMJMjAxMS0wNy0yMiAxNjozMTo0NS4wMDAwMDAw MDAgLTA0MDAKQEAgLTQ3LDYgKzQ3LDcgQEAgX19GQlNESUQoIiRGcmVlQlNEOiBoZWFkL3N5cy9u ZnNjbGllbnQvbgogI2luY2x1ZGUgPHN5cy9wcm9jLmg+CiAjaW5jbHVkZSA8c3lzL3NvY2tldC5o PgogI2luY2x1ZGUgPHN5cy9zeXNjdGwuaD4KKyNpbmNsdWRlIDxzeXMvdGFza3F1ZXVlLmg+CiAj aW5jbHVkZSA8c3lzL3Zub2RlLmg+CiAKICNpbmNsdWRlIDx2bS91bWEuaD4KQEAgLTU5LDYgKzYw LDggQEAgX19GQlNESUQoIiRGcmVlQlNEOiBoZWFkL3N5cy9uZnNjbGllbnQvbgogCiBzdGF0aWMg dW1hX3pvbmVfdCBuZnNub2RlX3pvbmU7CiAKK3N0YXRpYyB2b2lkCW5mc19mcmVlc2lsbHlyZW5h bWUodm9pZCAqYXJnLCBfX3VudXNlZCBpbnQgcGVuZGluZyk7CisKICNkZWZpbmUgVFJVRQkxCiAj ZGVmaW5lCUZBTFNFCTAKIApAQCAtMTg1LDYgKzE4OCwyMCBAQCBuZnNfbmdldChzdHJ1Y3QgbW91 bnQgKm1udHAsIG5mc2ZoX3QgKmZoCiAJcmV0dXJuICgwKTsKIH0KIAorLyoKKyAqIERvIHRoZSB2 cmVsZShzcC0+c19kdnApIGFzIGEgc2VwYXJhdGUgdGFzayBpbiBvcmRlciB0byBhdm9pZCBhCisg KiBkZWFkbG9jayBiZWNhdXNlIG9mIGEgTE9SIHdoZW4gdnJlbGUoKSBsb2NrcyB0aGUgZGlyZWN0 b3J5IHZub2RlLgorICovCitzdGF0aWMgdm9pZAorbmZzX2ZyZWVzaWxseXJlbmFtZSh2b2lkICph cmcsIF9fdW51c2VkIGludCBwZW5kaW5nKQoreworCXN0cnVjdCBzaWxseXJlbmFtZSAqc3A7CisK KwlzcCA9IGFyZzsKKwl2cmVsZShzcC0+c19kdnApOworCWZyZWUoc3AsIE1fTkZTUkVRKTsKK30K KwogaW50CiBuZnNfaW5hY3RpdmUoc3RydWN0IHZvcF9pbmFjdGl2ZV9hcmdzICphcCkKIHsKQEAg LTIwNyw4ICsyMjQsOCBAQCBuZnNfaW5hY3RpdmUoc3RydWN0IHZvcF9pbmFjdGl2ZV9hcmdzICph CiAJCSAqLwogCQkoc3AtPnNfcmVtb3ZlaXQpKHNwKTsKIAkJY3JmcmVlKHNwLT5zX2NyZWQpOwot CQl2cmVsZShzcC0+c19kdnApOwotCQlmcmVlKChjYWRkcl90KXNwLCBNX05GU1JFUSk7CisJCVRB U0tfSU5JVCgmc3AtPnNfdGFzaywgMCwgbmZzX2ZyZWVzaWxseXJlbmFtZSwgc3ApOworCQl0YXNr cXVldWVfZW5xdWV1ZSh0YXNrcXVldWVfdGhyZWFkLCAmc3AtPnNfdGFzayk7CiAJCW10eF9sb2Nr KCZucC0+bl9tdHgpOwogCX0KIAlucC0+bl9mbGFnICY9IE5NT0RJRklFRDsK ------=_Part_909765_1893841085.1311369086132 Content-Type: text/x-patch; name=newsilly.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=newsilly.patch LS0tIGZzL25mc2NsaWVudC9uZnNub2RlLmguc2F2MgkyMDExLTA3LTIyIDE1OjQyOjE0LjAwMDAw MDAwMCAtMDQwMAorKysgZnMvbmZzY2xpZW50L25mc25vZGUuaAkyMDExLTA3LTIyIDE1OjQzOjI1 LjAwMDAwMDAwMCAtMDQwMApAQCAtMzUsMTEgKzM1LDE0IEBACiAjaWZuZGVmIF9ORlNDTElFTlRf TkZTTk9ERV9IXwogI2RlZmluZQlfTkZTQ0xJRU5UX05GU05PREVfSF8KIAorI2luY2x1ZGUgPHN5 cy9fdGFzay5oPgorCiAvKgogICogU2lsbHkgcmVuYW1lIHN0cnVjdHVyZSB0aGF0IGhhbmdzIG9m ZiB0aGUgbmZzbm9kZSB1bnRpbCB0aGUgbmFtZQogICogY2FuIGJlIHJlbW92ZWQgYnkgbmZzX2lu YWN0aXZlKCkKICAqLwogc3RydWN0IHNpbGx5cmVuYW1lIHsKKwlzdHJ1Y3QJdGFzayBzX3Rhc2s7 CiAJc3RydWN0CXVjcmVkICpzX2NyZWQ7CiAJc3RydWN0CXZub2RlICpzX2R2cDsKIAlsb25nCXNf bmFtbGVuOwotLS0gZnMvbmZzY2xpZW50L25mc19jbG5vZGUuYy5zYXYyCTIwMTEtMDctMjIgMTU6 NDM6NDAuMDAwMDAwMDAwIC0wNDAwCisrKyBmcy9uZnNjbGllbnQvbmZzX2Nsbm9kZS5jCTIwMTEt MDctMjIgMTY6MzI6NTMuMDAwMDAwMDAwIC0wNDAwCkBAIC00Nyw2ICs0Nyw3IEBAIF9fRkJTRElE KCIkRnJlZUJTRDogaGVhZC9zeXMvZnMvbmZzY2xpZW4KICNpbmNsdWRlIDxzeXMvcHJvYy5oPgog I2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4KICNpbmNsdWRlIDxzeXMvc3lzY3RsLmg+CisjaW5jbHVk ZSA8c3lzL3Rhc2txdWV1ZS5oPgogI2luY2x1ZGUgPHN5cy92bm9kZS5oPgogCiAjaW5jbHVkZSA8 dm0vdW1hLmg+CkBAIC02NSw2ICs2Niw4IEBAIE1BTExPQ19ERUNMQVJFKE1fTkVXTkZTUkVRKTsK IAogdW1hX3pvbmVfdCBuZXduZnNub2RlX3pvbmU7CiAKK3N0YXRpYyB2b2lkCW5mc19mcmVlc2ls bHlyZW5hbWUodm9pZCAqYXJnLCBfX3VudXNlZCBpbnQgcGVuZGluZyk7CisKIHZvaWQKIG5jbF9u aGluaXQodm9pZCkKIHsKQEAgLTE4Niw2ICsxODksMjAgQEAgbmNsX25nZXQoc3RydWN0IG1vdW50 ICptbnRwLCB1X2ludDhfdCAqZgogCXJldHVybiAoMCk7CiB9CiAKKy8qCisgKiBEbyB0aGUgdnJl bGUoc3AtPnNfZHZwKSBhcyBhIHNlcGFyYXRlIHRhc2sgaW4gb3JkZXIgdG8gYXZvaWQgYQorICog ZGVhZGxvY2sgYmVjYXVzZSBvZiBhIExPUiB3aGVuIHZyZWxlKCkgbG9ja3MgdGhlIGRpcmVjdG9y eSB2bm9kZS4KKyAqLworc3RhdGljIHZvaWQKK25mc19mcmVlc2lsbHlyZW5hbWUodm9pZCAqYXJn LCBfX3VudXNlZCBpbnQgcGVuZGluZykKK3sKKwlzdHJ1Y3Qgc2lsbHlyZW5hbWUgKnNwOworCisJ c3AgPSBhcmc7CisJdnJlbGUoc3AtPnNfZHZwKTsKKwlmcmVlKHNwLCBNX05FV05GU1JFUSk7Cit9 CisKIGludAogbmNsX2luYWN0aXZlKHN0cnVjdCB2b3BfaW5hY3RpdmVfYXJncyAqYXApCiB7CkBA IC0yMjAsOCArMjM3LDggQEAgbmNsX2luYWN0aXZlKHN0cnVjdCB2b3BfaW5hY3RpdmVfYXJncyAq YQogCQkgKi8KIAkJbmNsX3JlbW92ZWl0KHNwLCB2cCk7CiAJCWNyZnJlZShzcC0+c19jcmVkKTsK LQkJdnJlbGUoc3AtPnNfZHZwKTsKLQkJRlJFRSgoY2FkZHJfdClzcCwgTV9ORVdORlNSRVEpOwor CQlUQVNLX0lOSVQoJnNwLT5zX3Rhc2ssIDAsIG5mc19mcmVlc2lsbHlyZW5hbWUsIHNwKTsKKwkJ dGFza3F1ZXVlX2VucXVldWUodGFza3F1ZXVlX3RocmVhZCwgJnNwLT5zX3Rhc2spOwogCQltdHhf bG9jaygmbnAtPm5fbXR4KTsKIAl9CiAJbnAtPm5fZmxhZyAmPSBOTU9ESUZJRUQ7Cg== ------=_Part_909765_1893841085.1311369086132-- From owner-freebsd-net@FreeBSD.ORG Fri Jul 22 21:23:44 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A572F1065672; Fri, 22 Jul 2011 21:23:44 +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 094808FC08; Fri, 22 Jul 2011 21:23:43 +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 p6MLNbQY023952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Jul 2011 00:23:37 +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 p6MLNbNf043367; Sat, 23 Jul 2011 00:23:37 +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 p6MLNacC043366; Sat, 23 Jul 2011 00:23:36 +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: Sat, 23 Jul 2011 00:23:36 +0300 From: Kostik Belousov To: Rick Macklem Message-ID: <20110722212336.GB17489@deviant.kiev.zoral.com.ua> References: <44626428-CF14-4B20-AB57-6D4E8F4678AE@averesystems.com> <1931983408.909766.1311369086133.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u7HsstwThBMwNUgg" Content-Disposition: inline In-Reply-To: <1931983408.909766.1311369086133.JavaMail.root@erie.cs.uoguelph.ca> 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: Jeremiah Lott , John Baldwin , freebsd-net@freebsd.org Subject: Re: LOR with nfsclient "sillyrename" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jul 2011 21:23:44 -0000 --u7HsstwThBMwNUgg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 22, 2011 at 05:11:26PM -0400, Rick Macklem wrote: > Jeremiah Lott wrote: > > We're seeing nfsclient deadlocks with what looks like lock order > > reversal after removing a "silly rename". It is fairly rare, but we've > > seen it happen a few times. I included relevant back traces from an > > occurrence. From what I can see, nfs_inactive() is called with the > > vnode locked. If there is a silly-rename, it will call vrele() on its > > parent directory, which can potentially try to lock the parent > > directory. Since this is the opposite order of the lock acquisition in > > lookup, it can deadlock. This happened in a FreeBSD7 build, but I > > looked through freebsd head and didn't see any change that addressed > > this. Anyone seen this before? > >=20 > > Jeremiah Lott > > Avere Systems > >=20 > Please try the attached patch (which is also at): > http://people.freebsd.org/~rmacklem/oldsilly.patch > http://people.freebsd.org/~rmacklem/newsilly.patch > (for the old and new clients in -current, respectively) >=20 > - I think oldsilly.patch should apply to the 7.n kernel > sources, although you might have to do the edit by hand? >=20 > The patch is based on what jhb@ posted, with changes as recommended > by kib@. >=20 > Please let me know how testing goes with it, rick > ps: Kostik, could you please review this, thanks. >=20 It looks fine to me, lets see how the testing goes. --u7HsstwThBMwNUgg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4p6lgACgkQC3+MBN1Mb4gThQCg3coFHpaNXcWomPxJPmTMl0/Z zNwAoLW5ClpZUSA2eP5veNSelmGXjn56 =yIlz -----END PGP SIGNATURE----- --u7HsstwThBMwNUgg-- From owner-freebsd-net@FreeBSD.ORG Fri Jul 22 22:33: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 08383106566B for ; Fri, 22 Jul 2011 22:33:47 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vw0-f45.google.com (mail-vw0-f45.google.com [209.85.212.45]) by mx1.freebsd.org (Postfix) with ESMTP id C00808FC13 for ; Fri, 22 Jul 2011 22:33:46 +0000 (UTC) Received: by vws17 with SMTP id 17so2842083vws.18 for ; Fri, 22 Jul 2011 15:33:46 -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=QOkHqLJmgYvGAI/D+t58UgoNx9CWR6D9z9hf8v15dmc=; b=SQTwAh2WAZQarQve6p1bdZ0JnBFj16X6fNSuGAFRD/g1RgNniqa0vf7V9cCeIwywwx tmo985+bdm/c8yJuZeaweUIltemGsG4xMXxw6MJ2Dk41l22czNf6FnVIlFG/QjGfiZiN e9PjEOk5ckvrq1RXyuSgkZ81Sa5lWfRo70Lds= MIME-Version: 1.0 Received: by 10.220.117.136 with SMTP id r8mr577692vcq.109.1311372622834; Fri, 22 Jul 2011 15:10:22 -0700 (PDT) Received: by 10.220.181.133 with HTTP; Fri, 22 Jul 2011 15:10:22 -0700 (PDT) Date: Fri, 22 Jul 2011 15:10:22 -0700 Message-ID: From: Garrett Cooper To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: What is slowhz? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jul 2011 22:33:47 -0000 I see this comment, and I've found references to a net.inet.tcp.slowhz in Free, Net, and OpenBSDs, but this value can't be queried anymore. # grep -r slowhz /sys/ /sys/netinet/ip.h:#define IPFRAGTTL 60 /* time to live for frags, slowhz */ Could someone please confirm that slowhz is indeed a half second value [1], or was it tunable / does it matter anymore? For additional context, I'm trying to map IP-MIB::ipReasmTimeout to a value used in the FreeBSD networking stack, and it looks like that value is the best candidate. Thanks! -Garrett 1. http://markmail.org/message/3xvte6uxrhyb4spn From owner-freebsd-net@FreeBSD.ORG Sat Jul 23 00:16:21 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5649D1065670 for ; Sat, 23 Jul 2011 00:16:21 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 16B118FC0A for ; Sat, 23 Jul 2011 00:16:20 +0000 (UTC) Received: by vxg33 with SMTP id 33so2635382vxg.13 for ; Fri, 22 Jul 2011 17:16:20 -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 :content-type:content-transfer-encoding; bh=5G2Z/BHZzyoIpizP+HRXk92Mu7bjQqiB2waLCSQEVq8=; b=gFgbeM+3IstU8qN4YlW/lfpZiOWsbr/pe5ho545jP2T5yAryR4RnT8t1TQleBxL6ZC VTpSMGHLbgF7oKQdkpepdKbiVo8wiJjqF5Ki6rPY5AWXrETTz+JfWpmh2vQHapp/YnNJ ZCqtxuFISEUH9oJOKHCGVa40iifesac/Saw9o= MIME-Version: 1.0 Received: by 10.220.57.11 with SMTP id a11mr629863vch.4.1311380178810; Fri, 22 Jul 2011 17:16:18 -0700 (PDT) Received: by 10.220.181.133 with HTTP; Fri, 22 Jul 2011 17:16:18 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Jul 2011 17:16:18 -0700 Message-ID: From: Garrett Cooper To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: What is slowhz? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jul 2011 00:16:21 -0000 On Fri, Jul 22, 2011 at 3:10 PM, Garrett Cooper wrote: > =A0 =A0I see this comment, and I've found references to a > net.inet.tcp.slowhz in Free, Net, and OpenBSDs, but this value can't > be queried anymore. > > # grep -r slowhz /sys/ > /sys/netinet/ip.h:#define =A0 =A0 =A0 IPFRAGTTL =A0 =A0 =A0 60 =A0 =A0 = =A0 =A0 =A0 =A0 =A0/* time to live for frags, slowhz */ > > =A0 =A0Could someone please confirm that slowhz is indeed a half second > value [1], or was it tunable / does it matter anymore? Answering my own question... /sys/sys/protosw.h: ... * every 500ms through the pr_slowtimo for timer based actions. ... #define PR_SLOWHZ 2 /* 2 slow timeouts per second */ > =A0 =A0For additional context, I'm trying to map IP-MIB::ipReasmTimeout > to a value used in the FreeBSD networking stack, and it looks like > that value is the best candidate. This is of course IP-MIB::ipReasmTimeout =3D IFRAGTTL / PR_SLOWHZ =3D 30 se= conds. > 1. http://markmail.org/message/3xvte6uxrhyb4spn Thanks! -Garrett From owner-freebsd-net@FreeBSD.ORG Sat Jul 23 01:36:17 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85A091065672 for ; Sat, 23 Jul 2011 01:36:17 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id EA69C8FC1D for ; Sat, 23 Jul 2011 01:36:16 +0000 (UTC) Received: from [IPv6:2001:470:28:140:11c1:1016:bdbf:959f] ([IPv6:2001:470:28:140:11c1:1016:bdbf:959f]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.4) with ESMTP id p6N1aAx0076496 for ; Sat, 23 Jul 2011 04:36:11 +0300 (EEST) (envelope-from universite@ukr.net) Message-ID: <4E2A2575.2090601@ukr.net> Date: Sat, 23 Jul 2011 04:35:49 +0300 From: "Vladislav V. Prodan" 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: freebsd-net@freebsd.org References: <4E284D09.9060308@ukr.net> <4E29BB7B.5000704@delphij.net> In-Reply-To: <4E29BB7B.5000704@delphij.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-95.5 required=5.0 tests=FREEMAIL_FROM,FSL_RU_URL, RDNS_NONE, SPF_SOFTFAIL, T_TO_NO_BRKTS_FREEMAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mary-teresa.otrada.od.ua X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (otrada.od.ua [IPv6:2001:470:28:140::5]); Sat, 23 Jul 2011 04:36:15 +0300 (EEST) Subject: Re: I want to change the ToS / DSCP on FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jul 2011 01:36:17 -0000 22.07.2011 21:03, Xin LI wrote: > https://github.com/yahoo/l3dsr/tree/master/ > > We should probably make a port or import it into the base system, I think? Thanks for the link. I'll watch the code. -- Vladislav V. Prodan VVP24-UANIC +380[67]4584408 +380[99]4060508 vlad11@jabber.ru From owner-freebsd-net@FreeBSD.ORG Sat Jul 23 01:43:02 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34F31106564A; Sat, 23 Jul 2011 01:43:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id C0C858FC18; Sat, 23 Jul 2011 01:43:01 +0000 (UTC) Received: by gyf3 with SMTP id 3so1919173gyf.13 for ; Fri, 22 Jul 2011 18:43:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=B2Mn1UQZwQeQufA7xqqzk4IqOVXMg39CrvLCJ+lCj6s=; b=u7py7Lw+4QEs683a2LMs58ZET+qxhLDbVq9kWJzkZ/xewoKTP5t4NXP4uUYBT008d5 1RcLbVwPK6g5CDTk1f4zIwIIyG4Xn2pD2W0eIFBSDrklRRh9g3fDoTeScB6k0nEHbDKX 58iRKN9s7ouKVaV/o3gIhRc/uwL25BJq1dZLs= MIME-Version: 1.0 Received: by 10.150.252.6 with SMTP id z6mr2521700ybh.101.1311385379754; Fri, 22 Jul 2011 18:42:59 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.150.197.5 with HTTP; Fri, 22 Jul 2011 18:42:59 -0700 (PDT) In-Reply-To: <4E246C95.40601@gmail.com> References: <201107140702.p6E721Y4012318@freefall.freebsd.org> <4E246C95.40601@gmail.com> Date: Sat, 23 Jul 2011 09:42:59 +0800 X-Google-Sender-Auth: 8ERm6AkYcJAaiBjzhdAd_FW1N7w Message-ID: From: Adrian Chadd To: Matt Content-Type: text/plain; charset=ISO-8859-1 Cc: ae@freebsd.org, freebsd-wireless@freebsd.org, freebsd-net@freebsd.org 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: Sat, 23 Jul 2011 01:43:02 -0000 When do we just give in and commit this merged code for now? Adrian On 19 July 2011 01:25, Matt wrote: > On 07/14/11 00:02, ae@FreeBSD.org wrote: >> >> 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 >> _______________________________________________ >> freebsd-wireless@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-wireless >> To unsubscribe, send any mail to >> "freebsd-wireless-unsubscribe@freebsd.org" >> > This is in progress...either from OpenBSD or from Alexandr's rt2860 code. > Or a merge of the two. > > In the mean time, anyone interested should please test. > It seems like it may not work on anything but current, but I don't have > enough information to be sure. > > Patches (rt2860 merged with ral): > https://docs.google.com/leaf?id=0B6YlMzJxarGbMWFmZDUxMTgtOTU4ZC00MjRlLThhMTctZTE1MDcwNDJiZDIx&hl=en_US > > If you have build errors, please provide output of uname -a, and copying > exact error messages if any. > > Thanks, > Matt > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sat Jul 23 03:09: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 2A90A106564A for ; Sat, 23 Jul 2011 03:09:11 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx06.syd.optusnet.com.au (fallbackmx06.syd.optusnet.com.au [211.29.132.8]) by mx1.freebsd.org (Postfix) with ESMTP id A74818FC13 for ; Sat, 23 Jul 2011 03:09:10 +0000 (UTC) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p6N0M1EM020833 for ; Sat, 23 Jul 2011 10:22:01 +1000 Received: from c122-106-165-191.carlnfd1.nsw.optusnet.com.au (c122-106-165-191.carlnfd1.nsw.optusnet.com.au [122.106.165.191]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p6N0Liea011480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Jul 2011 10:21:59 +1000 Date: Sat, 23 Jul 2011 10:21:44 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Vladimir Budnev In-Reply-To: Message-ID: <20110723100828.S4156@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org Subject: Re: What does define COMMENT_ONLY mean? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jul 2011 03:09:11 -0000 On Fri, 22 Jul 2011, Vladimir Budnev wrote: > What does this define > > COMMENT_ONLY > > mean and what for it is used? Try googling the structure hack (I didn't). > Iv met such one in if_arp.h source in freebsd kernel, but cant get such > strange if in arp header structure. > > -----------------------------------example > struct arphdr { > <...> > /* > * The remaining fields are variable in size, > * according to the sizes above. > */ > #ifdef COMMENT_ONLY > u_char ar_sha[]; /* sender hardware address */ > u_char ar_spa[]; /* sender protocol address */ > u_char ar_tha[]; /* target hardware address */ > u_char ar_tpa[]; /* target protocol address */ > #endif > }; C didn't support support variable-sized structs before C99, and doesn't really support them now. Various hacks are used to make pseudo-structs larger or smaller than ones that can actually be declared work. The above is one. The pseudo-struct is malloc()ed and has size larger than the declared one. The above says what would be in it if it could be declared. If this were written in C99, it might declare u_char ar_foo[] in the the code instead of in a comment. But C can't really support variable- sized structs. It only allows one ar_foo[], which must be at the end of the struct. ar_foo then has a known offset but an unknown size. The other ar_bar[]'s still can't be declared, since they want to be further beyond the end of the struct, which places them at an unknown offset. A probably-less-unportable way was to declare everything in the struct but malloc() less. This only works if all the magic fields are at known offsets. This doesn't work in the above, since the fields want to have variable lengths each and thus end up at variable offsets. Such fields can be allocated from a single larger field (usually an an array), but you lose the possibility of declaring them all. Bruce From owner-freebsd-net@FreeBSD.ORG Sat Jul 23 04:54:36 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FBEE106564A; Sat, 23 Jul 2011 04:54:36 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 374048FC08; Sat, 23 Jul 2011 04:54:35 +0000 (UTC) Received: by pzk5 with SMTP id 5so14214215pzk.17 for ; Fri, 22 Jul 2011 21:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=115B45EpCRPoqCl5YtNGe+NIQ0MlXD5q8rIAiRxIsko=; b=a5CiaxO1Ptg3+qleMcSdbJ1+HelPz+LamjzJaoqbtnliBRdAX4F8Rpjg+Xx05pGn/m Q2cWk7/BLFwAfJhGwnylPLNXHQf7Bz45ssozNJHuX6q3B7uYSwYtQCiYx06OEBHzLW3N oXkxKCBlVHZeOKoeOdVXAxIfxDHnIcfS8NCqU= Received: by 10.68.41.168 with SMTP id g8mr3610171pbl.512.1311396875593; Fri, 22 Jul 2011 21:54:35 -0700 (PDT) Received: from sidhe.local ([75.111.38.94]) by mx.google.com with ESMTPS id k3sm1132741pbj.93.2011.07.22.21.54.32 (version=SSLv3 cipher=OTHER); Fri, 22 Jul 2011 21:54:33 -0700 (PDT) Message-ID: <4E2A5407.7080808@gmail.com> Date: Fri, 22 Jul 2011 21:54:31 -0700 From: Matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110716 Thunderbird/5.0 MIME-Version: 1.0 To: Adrian Chadd References: <201107140702.p6E721Y4012318@freefall.freebsd.org> <4E246C95.40601@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ae@freebsd.org, freebsd-wireless@freebsd.org, freebsd-net@freebsd.org 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: Sat, 23 Jul 2011 04:54:36 -0000 On 07/22/11 18:42, Adrian Chadd wrote: > When do we just give in and commit this merged code for now? > > > Adrian > > On 19 July 2011 01:25, Matt wrote: >> On 07/14/11 00:02, ae@FreeBSD.org wrote: >>> 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 >>> _______________________________________________ >>> freebsd-wireless@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>> To unsubscribe, send any mail to >>> "freebsd-wireless-unsubscribe@freebsd.org" >>> >> This is in progress...either from OpenBSD or from Alexandr's rt2860 code. >> Or a merge of the two. >> >> In the mean time, anyone interested should please test. >> It seems like it may not work on anything but current, but I don't have >> enough information to be sure. >> >> Patches (rt2860 merged with ral): >> https://docs.google.com/leaf?id=0B6YlMzJxarGbMWFmZDUxMTgtOTU4ZC00MjRlLThhMTctZTE1MDcwNDJiZDIx&hl=en_US >> >> If you have build errors, please provide output of uname -a, and copying >> exact error messages if any. >> >> Thanks, >> Matt >> _______________________________________________ >> freebsd-wireless@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-wireless >> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" >> That may be a good stopgap! My next step is to go line by line through OpenBSD ral & existing FreeBSD ral and try to find a way to either create an abstraction layer for easy porting or otherwise structure our driver to successfully "eat" OpenBSD changes in the future. This will take significant time on my part, as I am a noobophyte :). If anyone knows of useful tools for organizing very large C sources by function please let me know, it would help! I will do some major hacking at it tonight I suppose...it's about time :). I'll post updates sometime soon, but OpenBSD's 80211 stack seems quite different than ours...pci stuff is all different for sure. Matt From owner-freebsd-net@FreeBSD.ORG Sat Jul 23 18:02:56 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C0441065670 for ; Sat, 23 Jul 2011 18:02:56 +0000 (UTC) (envelope-from dima_bsd@inbox.lv) Received: from smtp3.apollo.lv (smtp3.apollo.lv [80.232.168.198]) by mx1.freebsd.org (Postfix) with ESMTP id 5E4A28FC08 for ; Sat, 23 Jul 2011 18:02:56 +0000 (UTC) Received: from [46.109.211.70] (unknown [46.109.211.70]) by smtp3.apollo.lv (Postfix) with ESMTP id 3674F11EC50; Sat, 23 Jul 2011 20:44:31 +0300 (EEST) From: Dmitriy Demidov Date: Sat, 23 Jul 2011 17:44:29 +0000 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Disposition: inline To: ae@FreeBSD.org, freebsd-net@FreeBSD.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201107231744.29444.dima_bsd@inbox.lv> X-Brightmail-Tracker: AAAAAA== Cc: Subject: Re: kern/143939: [ipfw] [em] ipfw nat and em interface rxcsum 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: Sat, 23 Jul 2011 18:02:56 -0000 Hi, I have tested this config on today's CURRENT, and i do not got any problems with ipfw nat on em. Looks like problem is solved - UDP traffic is not damaged anymore! Thanks. ===================== em0@pci0:2:9:0: class=0x020000 card=0x30138086 chip=0x100e8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82540EM Gigabit Ethernet Controller' class = network subclass = ethernet em0: port 0xa400-0xa43f mem 0xdb200000-0xdb21ffff irq 21 at device 9.0 on pci2 em0: Ethernet address: 00:20:ed:71:45:67 uname -a FreeBSD celeron 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Sat Jul 23 16:24:58 EEST 2011 root@celeron:/usr/obj/usr/src/sys/GENERIC i386 celeron# ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=209b ether 00:20:ed:71:45:67 inet 46.109.209.50 netmask 0xfffff800 broadcast 255.255.255.255 nd6 options=29 media: Ethernet autoselect (100baseTX ) status: active celeron# ipfw nat 1 show config ipfw nat 1 config if em0 log deny_in same_ports reset celeron# ipfw show 00100 24 3398 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 00400 0 0 deny ip from any to ::1 00500 0 0 deny ip from ::1 to any 00600 0 0 allow ipv6-icmp from :: to ff02::/16 00700 0 0 allow ipv6-icmp from fe80::/10 to fe80::/10 00800 0 0 allow ipv6-icmp from fe80::/10 to ff02::/16 00900 0 0 allow ipv6-icmp from any to any ip6 icmp6types 1 01000 0 0 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136 01100 918 98707 allow ip from any to any via fxp1 01200 339 54933 nat 1 ip from any to any via em0 01300 0 0 deny ip from any to any 65535 0 0 deny ip from any to any ===================== From owner-freebsd-net@FreeBSD.ORG Sat Jul 23 19:38:58 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 69638106566B for ; Sat, 23 Jul 2011 19:38:58 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 51EE38FC14 for ; Sat, 23 Jul 2011 19:38:58 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qki2L-0009Z8-Lb; Sat, 23 Jul 2011 19:38:57 +0000 Date: Sat, 23 Jul 2011 15:38:57 -0400 Message-ID: From: Randy Bush To: FreeBSD Net User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: netflix from japan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jul 2011 19:38:58 -0000 netflix streaming is not allowed to japan where we live. i can tunnel to a server in one of my racks in the states. the tokyo border is a soekris running FreeBSD 8. it will kinda look like .------------------------------. | | | b --wlan0| ...... Apple TV | r | WAN IIJ | i --- vr1| PPP/NAT ---|vr0[PPPoE][ppp]tun0--d | 192.168.0.0/24 Public IP Addr | g --- vr2| LAN hosts, | e | DHCP Clients | 0 --- vr3| ... | | `------------------------------' --- % cat /etc/ppp/ppp.conf iij: set device PPPoE:vr0 set MRU 1454 set MTU 1454 accept CHAP enable lqr add default HISADDR nat enable yes nat port tcp 192.168.0.33:51332 51332 nat port udp 192.168.0.33:51332 51332 nat port tcp 192.168.0.12:22 42022 set authname foo set authkey bar --- there seem to be at least two sets of problems o what are the ip addys and ports involved in netflix streaming set-up and delivery? o how to tunnel just those to/from a server in the states? anyone with suggestions? randy