From owner-freebsd-net@FreeBSD.ORG Sun Jul 14 10:03:53 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ED375158 for ; Sun, 14 Jul 2013 10:03:53 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by mx1.freebsd.org (Postfix) with ESMTP id C935BBAD for ; Sun, 14 Jul 2013 10:03:53 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id hz11so10250507pad.2 for ; Sun, 14 Jul 2013 03:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=gLoY6n4/s1puF+BW+3r7xYXWursM2VI0CG22i21Tr7A=; b=UL1LdugOXsCn5HjgtGGS5ocIcyubZ0Goyz2BYEQvp0SxieApA1LwlScNaWfSSuA88r VS4Rqngk5PTTAXesbRTz0r/C3vcLoVGV/OskNq9YnCj29VNALNNmL+MpDY8d+o70Vysq REwzyWGLhL4xtDUZEGc9Z/YbgD3CLUVcErUsnj84zPJdcNh+VbL8VzEvZ0V2qkzDrGpn qqWeChF+UtQd24TN2rxOSmHZ6mp3KBPuijo4BxS8KYYrTNEWVOn8vQCjAN6UIBkTN1tj wtm4RaOZaa9sWwOHlc5+qRQFan0oE+M7Ew9rCfuFZRSZr+seBuruRDOgFhU+qVBhSsXp 0Lrw== X-Received: by 10.68.252.233 with SMTP id zv9mr48877338pbc.69.1373796233568; Sun, 14 Jul 2013 03:03:53 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id z14sm41755997pbt.0.2013.07.14.03.03.50 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 14 Jul 2013 03:03:52 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 14 Jul 2013 19:03:48 +0900 From: Yonghyeon PYUN Date: Sun, 14 Jul 2013 19:03:47 +0900 To: Andreas Longwitz Subject: Re: sis(4) flow control Message-ID: <20130714100347.GA1105@michelle.cdnetworks.com> References: <51DC1599.8040805@incore.de> <20130710023512.GB2753@michelle.cdnetworks.com> <51DDDDAB.6070100@incore.de> <20130711002557.GA6697@michelle.cdnetworks.com> <51E1B8F0.5030100@incore.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51E1B8F0.5030100@incore.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 10:03:54 -0000 On Sat, Jul 13, 2013 at 10:30:40PM +0200, Andreas Longwitz wrote: > Yonghyeon PYUN wrote: > > >>> Try attached patch and let me know how it works. > >> Thanks for your patch. I will test it on next update of my soekris boxes > >> with sis interfaces. Because they are all remote far away this will need > >> some time. > > > > Ok. Make sure to check established link before testing > > flow-control. 'ifconfig sis0' will show current media and you > > should have something like the following. > > ... > > media: Ethernet autoselect (100baseTX ) > > > > If you don't see 'rxpause', re-negotiate flow-control with > > 'ifconfig sis0 mediaopt flow'. > > Because sis(4) (soekris 4801) is not available for me at the moment, I > tried with vr(4) (soekris 5501). In production I run both types of boxes > with FreeBSD 6 and a simple SETBIT patch to honor RX pause frames. > Now I want to go with FreeBSD 8 Stable and eliminate my patch. > > "ifconfig vr0" gives > media: Ethernet autoselect (100baseTX ), > therefore I tried (using serial console) "ifconfig vr0 flow" > and now "ifconfig vr0" as expected gives > media: Ethernet autoselect (100baseTX > ), > but the interface vr0 hangs. Outgoing packets are ok, but all incoming > packets are blocked. In this situation I can give "ifconfig vr0 > -mediaopt flowcontrol" and see after "ifconfig vr0" > media: Ethernet autoselect (none) > status: no carrier > and one second later > media: Ethernet autoselect (100baseTX ) > status: active > and interface works correct again. > Hmm, I recall flow control worked on VT6105 when I initially added the feature but it seems there is an issue on that. vr(4) needs driver assistance to generate TX pause frames so I guess vr(4) may not be good link partner to verify flow-control. vr(4) controllers also does not have hardware MAC counters so it would be hard to know how many pause frames were processed in the controller. > >From console: > vr0: port 0xe100-0xe1ff mem > 0xa0004000-0xa00040ff irq 11 at device 6.0 on pci0 > vr0: Quirks: 0x2 > vr0: Revision: 0x96 > miibus0: on vr0 > ukphy0: PHY 1 on miibus0 > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, > auto-flow > vr0: Ethernet address: 00:00:24:cb:1e:34 > vr0: [ITHREAD] > > My switch is D-Link DGS-1008D green Ethernet (has support for IEEE > 802.3x Flow-Control). On the same switch I have connected two other > machines using msk driver (88E8050 and 88E8055) and "ifconfig msk0" > gives always > media: Ethernet autoselect (1000baseT > ) > > Maybe there is a bug in vr(4) that generates the hang, but why is Probably yes and I shall have to narrow down the issue. > negotiation of flowcontrol on vr(4) not done at boot time as shown for > msk(4) ? > msk(4) supported flow-control from day 1 with a hack and it was re-implemented later with proper way such that it always announces flow-control. However for other drivers(i.e vr(4)) that didn't support the feature in the beginning, you have to explicitly enable the feature. The decision was made to provide compatibility and to not introduce POLA. > If you need more information about the hang let me know. I guess it would be good idea to use a link partner that shows hardware MAC statistics. If your switch provides such information that's fine. If you use direct connection between two hosts without switch, use other network drivers(most gigabit controllers support hardware MAC counters). From owner-freebsd-net@FreeBSD.ORG Sun Jul 14 14:20:31 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5F4BE570; Sun, 14 Jul 2013 14:20:31 +0000 (UTC) (envelope-from claudiu.vasadi@gmail.com) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 2CE18256; Sun, 14 Jul 2013 14:20:31 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id 16so24313936iea.17 for ; Sun, 14 Jul 2013 07:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t35wM1paV5TEVuS6Aeak4OS/UC7TBzW4/DEPtV0kiqo=; b=hYvy3aOu0NplHg9mvoSAjxLexNPRLowqWtp3Rr2Yf8SxCvtcnXP3PID5+tLoGMpowf v0lwg8qZhYg4rJaACSrND3X4g9SW+rmsEvt4/j2QfQj9ZzzfIAYbpyNIHTlIp/tZ1tRM eJVM8/hpn5deKgwW3F1wX7iU93w6GTs3AO/xbT05P2MFkYeIXOxHov+JHtDZ/JEmBPO8 AnIyNR1rVAjuQ3uh04mJvlzDIc80lIWTN+cnFZchIXAv/HXNb7HqcvUbutyOOqqO7/9j Bnayd64YuaxIAHLuUdbWJS7mtq2GMUpnTRz3vvJ6cm8ngsMVMYjnrOyg5dE45+EMchp6 NeZQ== MIME-Version: 1.0 X-Received: by 10.50.20.232 with SMTP id q8mr4928307ige.0.1373811630817; Sun, 14 Jul 2013 07:20:30 -0700 (PDT) Received: by 10.64.56.67 with HTTP; Sun, 14 Jul 2013 07:20:30 -0700 (PDT) In-Reply-To: <201307091122.r69BM9Ev053001@freefall.freebsd.org> References: <201307091122.r69BM9Ev053001@freefall.freebsd.org> Date: Sun, 14 Jul 2013 16:20:30 +0200 Message-ID: Subject: Re: kern/180382: [ae] kernel: ae0: watchdog timeout - resetting. From: claudiu vasadi To: yongari@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jul 2013 14:20:31 -0000 Hi, The patch applied without any problems and the "Size mismatch" messages are gone now. However, we cannot get an IP via "dhclient" and we also don't have any network connectivity if we set a manual IP. The only messages we see now (with the manual IP) is "no buffer space available". I checked the Ip, netmask, gateway and mbufs but they all seem to be ok. "ifconfg ae0 down && ifconfig ae0 up" does not fix the problem. We also tried a reboot but again, it did not fix the problem. We have no ping or anything. No other error messages were observed. PS: Sorry for the late reply but the machine is on a remote site. PS2: I can arrange a ssh account if this would help you. On Tue, Jul 9, 2013 at 1:22 PM, wrote: > Synopsis: [ae] kernel: ae0: watchdog timeout - resetting. > > State-Changed-From-To: open->feedback > State-Changed-By: yongari > State-Changed-When: Tue Jul 9 11:21:13 UTC 2013 > State-Changed-Why: > Would you try patch at the following URL? > http://freefall.freebsd.org/~yongari/ae.diff > > > Responsible-Changed-From-To: freebsd-net->yongari > Responsible-Changed-By: yongari > Responsible-Changed-When: Tue Jul 9 11:21:13 UTC 2013 > Responsible-Changed-Why: > Grab. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=180382 > -- Best regards, Claudiu Vasadi From owner-freebsd-net@FreeBSD.ORG Sun Jul 14 15:20:31 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3CB1DF59; Sun, 14 Jul 2013 15:20:31 +0000 (UTC) (envelope-from trociny@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 18E2060D; Sun, 14 Jul 2013 15:20:31 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6EFKUEY077789; Sun, 14 Jul 2013 15:20:30 GMT (envelope-from trociny@freefall.freebsd.org) Received: (from trociny@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6EFKTYE077783; Sun, 14 Jul 2013 15:20:29 GMT (envelope-from trociny) Date: Sun, 14 Jul 2013 15:20:29 GMT Message-Id: <201307141520.r6EFKTYE077783@freefall.freebsd.org> To: freebsd@grem.de, trociny@FreeBSD.org, freebsd-net@FreeBSD.org, trociny@FreeBSD.org From: trociny@FreeBSD.org Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jul 2013 15:20:31 -0000 Synopsis: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly State-Changed-From-To: open->patched State-Changed-By: trociny State-Changed-When: Sun Jul 14 15:18:10 UTC 2013 State-Changed-Why: The fix is committed. Responsible-Changed-From-To: freebsd-net->trociny Responsible-Changed-By: trociny Responsible-Changed-When: Sun Jul 14 15:18:10 UTC 2013 Responsible-Changed-Why: Will close after MFC r253282. http://www.freebsd.org/cgi/query-pr.cgi?pr=179901 From owner-freebsd-net@FreeBSD.ORG Sun Jul 14 16:17:14 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B195EBC5 for ; Sun, 14 Jul 2013 16:17:14 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm27-vm2.bullet.mail.ne1.yahoo.com (nm27-vm2.bullet.mail.ne1.yahoo.com [98.138.91.215]) by mx1.freebsd.org (Postfix) with ESMTP id 78E6A7F9 for ; Sun, 14 Jul 2013 16:17:14 +0000 (UTC) Received: from [98.138.90.52] by nm27.bullet.mail.ne1.yahoo.com with NNFMP; 14 Jul 2013 16:14:22 -0000 Received: from [98.138.226.160] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 14 Jul 2013 16:14:22 -0000 Received: from [127.0.0.1] by omp1061.mail.ne1.yahoo.com with NNFMP; 14 Jul 2013 16:14:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 55637.81867.bm@omp1061.mail.ne1.yahoo.com Received: (qmail 74274 invoked by uid 60001); 14 Jul 2013 16:14:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1373818461; bh=6AvwuNxxQ6LimiclbZ+8oK0W0EqGX/oWHsilJiJxktQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ea4VYWCSEvaXDosMHzQlZ/uzXxEJSOkdRw/K2EHZu+eqa+gOdhOSSk/TADklac72S98Dx3pSMLqsiMZAo0wC8a/WaxlpYamjXQB9c1O2n5WxdtQKSE4Y7W1Y5zyCnM79TeEUjYwgfXagu7s3Lu2SGio3569mL9rfjC9T3auUf1U= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=JDKtTt8j+gfAcbvs+APdIH2S1ySGSWZ15Nw6tKoVc+JO2gULqtE3DTCal9OnNkimSlfT0InJLoPgTlXZhxlz8/2HbQxWIu9iq17k4FdzVCDmPdthLreznifIwrrd+RUVQEtUs3Ojc0FQMlQf4nQPlH3VVWjMPC4Xh+zTw4fj4QI= ; X-YMail-OSG: qbEz.NwVM1nV5XZcmFxEViBMPDxSjdij2TjKgTjfq8Xo_uD xtS7tkUmiaTPn2kS7o.WfkZuX4Sg7uTtnaa5AEXvfCh9SSejSDsqSegsO67A 20__l28Rpe1JzTVbbg_mZ_esCmY3ivRUG5g4mFWG7BpFZHTkbQsMEJuH8WHv yYDJNP0ntYUf3gJ19q0UHbb_u4NLGhf5yqUi75ZWKixwYANb_sQ9oV_Le9FA dh2MaqdigS76UsmfWzjU7ty34Ahx3UJ61oHxJm_UF4u7j5jZ763Yhj7YS6KZ gG.us8tjsmWq6Nf7dy9VhzZ9QC6JnmuGPVQirqDOYpoz6Jovbh2rg8yrnz8J 2_IgF8uXHwNk6pMV2ZJZ9WGOh2S4C_fvzzR.5rz8jja_o6dMhk9JdKfKTjCv ZFr9YsTAjV90kwhQuxfuZ3bXsKZCq6.1D6QRZbia2qUdUG5KWfi8nZRzLM9K UM6iVWe5rgLscRrXPXvX1u_DdvlqdxTBTWOWAwDpgG9qOYgh0xDsa3ZG0ugk G_M_GhgEjKFBVgQ5tw7_zw8HNMqeNVR9NAUOK3NE36YSjGXYtWuAuddc5WyK yFfY.tYlLdNlNzbpSRmmvGTs- Received: from [98.203.118.124] by web121605.mail.ne1.yahoo.com via HTTP; Sun, 14 Jul 2013 09:14:21 PDT X-Rocket-MIMEInfo: 002.001, U28gd2h5IG5vdCBnZXQgYSByZWFsIDEwZ2IvcyBjYXJkPyBSSjQ1IDEwZ2lnIGlzIGhlcmUsIA0KYW5kIGl0IHdvcmtzIGEgbG90IGJldHRlciB0aGFuIExBR0cuDQoNCklmIHlvdSB3YW50IHRvIGdldCBtb3JlIHRoYW4gMUdiL3Mgb24gYSBzaW5nbGUgY29ubmVjdGlvbiwNCnlvdSdkIG5lZWQgdG8gdXNlIHJvdW5kcm9iaW4sIHdoaWNoIHdpbGwgYWx0ZXJuYXRlIHBhY2tldHMNCndpdGhvdXQgY29uY2VybiBmb3Igb3JkZXJpbmcuIFB1cmlzdHMgd2lsbCBhcmd1ZSBhZ2FpbnN0IGl0LA0KYnV0IGl0IGRvZXMBMAEBAQE- X-Mailer: YahooMailClassic/1000012 YahooMailWebService/0.8.148.557 Message-ID: <1373818461.35904.YahooMailBasic@web121605.mail.ne1.yahoo.com> Date: Sun, 14 Jul 2013 09:14:21 -0700 (PDT) From: Barney Cordoba Subject: Re: Re[2]: FreeBSD router problems To: isp In-Reply-To: <3798.1373566301.16193856550018220032@ffe15.ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jul 2013 16:17:14 -0000 So why not get a real 10gb/s card? RJ45 10gig is here,=20 and it works a lot better than LAGG. If you want to get more than 1Gb/s on a single connection, you'd need to use roundrobin, which will alternate packets without concern for ordering. Purists will argue against it, but it does work and modern TCP stacks know how to deal=20 with out of order packets. ifconfig lagg0 laggproto roundrobin laggport em0 laggport em1 BC -------------------------------------------- On Thu, 7/11/13, isp wrote: Subject: Re[2]: FreeBSD router problems To: "Alan Somers" Cc: freebsd-net@freebsd.org Date: Thursday, July 11, 2013, 2:11 PM =20 =20 =20 =20 I have a real network with more than 4 000 users. In normal case, when I have two 1Gbps routers, and I split VLAN's between them total bandwidth if growing up to 1.7 Gbps. =20 --- Incoming mail --- From: "Alan Somers" Date: 11 July 2013, 21:00:41 =20 How are you benchmarking it?=C2=A0 Each TCP connection only uses one member of a lagg port.=C2=A0 So if you want to see > 1 Gbps, you'll need to benchmark with multiple TCP connections.=C2=A0 You may also need multiple systems; I don't know the full details of LACP. =20 On Thu, Jul 11, 2013 at 11:32 AM, isp <=C2=A0 mline@ukr.net=C2=A0 > wrote: > > > > Hi! I have a problem with my FreeBSD router, I can't get more than 1 Gbps > throught it, but I have 2 Gbps LAGG on it. There are only 27 IPFW rules > (NAT+Shaping). IPoE only. > lagg0 (VLAN's + shaping) - two 'igb' adapters > lagg1 (NAT, tso if off) - two 'em' adapters > > I tried to switch off dummynet, but it doesn't helps. > > # uname -a > [code]FreeBSD router 9.1-RELEASE-p3 FreeBSD 9.1-RELEASE-p3 #0: Tue Apr 30 > 20:02:00 EEST 2013=C2=A0 =C2=A0=C2=A0=C2=A0root@south:/usr/obj/usr/src/sys/ROUTER=C2=A0 amd64 > > # top -aSPHI > last pid: 91712;=C2=A0 load averages:=C2=A0 2.18,=C2=A0 2.06, > 1.97 > up 20+22:28:36=C2=A0 17:40:22 > 120 processes: 7 running, 87 sleeping, 26 waiting > CPU 0:=C2=A0 0.0% user,=C2=A0 0.0% nice,=C2=A0 1.6% system, 38.6% interrupt, 59.8% idle > CPU 1:=C2=A0 0.0% user,=C2=A0 0.0% nice,=C2=A0 7.1% system, 37.0% interrupt, 55.9% idle > CPU 2:=C2=A0 0.0% user,=C2=A0 0.0% nice,=C2=A0 3.9% system, 38.6% interrupt, 57.5% idle > CPU 3:=C2=A0 0.0% user,=C2=A0 0.0% nice, 15.7% system, 26.8% interrupt, 57.5% idle > Mem: 59M Active, 1102M Inact, 942M Wired, 800M Buf, 5529M Free > Swap: 16G Total, 16G Free > > PID USERNAME PRI NICE=C2=A0=C2=A0=C2=A0SIZE=C2=A0 =C2=A0 RES STATE=C2=A0=C2=A0=C2=A0C=C2=A0=C2=A0=C2=A0TIME=C2=A0=C2=A0=C2=A0WCPU COMMAND > 12 root=C2=A0 =C2=A0=C2=A0=C2=A0-72=C2=A0 =C2=A0 -=C2=A0 =C2=A0=C2=A0=C2=A00K=C2=A0=C2=A0=C2=A0448K RUN=C2=A0 =C2=A0=C2=A0=C2=A01 153:39 72.22% [intr{swi1: > netisr 0}] > 11 root=C2=A0 =C2=A0=C2=A0=C2=A0155 ki31=C2=A0 =C2=A0=C2=A0=C2=A00K=C2=A0 =C2=A0 64K RUN=C2=A0 =C2=A0=C2=A0=C2=A01 494.2H 65.19% [idle{idle: > cpu1}] > 11 root=C2=A0 =C2=A0=C2=A0=C2=A0155 ki31=C2=A0 =C2=A0=C2=A0=C2=A00K=C2=A0 =C2=A0 64K CPU2=C2=A0 =C2=A0 2 494.3H 64.65% [idle{idle: > cpu2}] > 11 root=C2=A0 =C2=A0=C2=A0=C2=A0155 ki31=C2=A0 =C2=A0=C2=A0=C2=A00K=C2=A0 =C2=A0 64K RUN=C2=A0 =C2=A0=C2=A0=C2=A00 493.3H 63.38% [idle{idle: > cpu0}] > 11 root=C2=A0 =C2=A0=C2=A0=C2=A0155 ki31=C2=A0 =C2=A0=C2=A0=C2=A00K=C2=A0 =C2=A0 64K CPU3=C2=A0 =C2=A0 3 496.4H 62.55% [idle{idle: > cpu3}] > 12 root=C2=A0 =C2=A0=C2=A0=C2=A0-92=C2=A0 =C2=A0 -=C2=A0 =C2=A0=C2=A0=C2=A00K=C2=A0=C2=A0=C2=A0448K WAIT=C2=A0 =C2=A0 2=C2=A0 58:49=C2=A0 9.38% [intr{irq266: > igb0:que}] > 12 root=C2=A0 =C2=A0=C2=A0=C2=A0-92=C2=A0 =C2=A0 -=C2=A0 =C2=A0=C2=A0=C2=A00K=C2=A0=C2=A0=C2=A0448K WAIT=C2=A0 =C2=A0 2=C2=A0 59:32=C2=A0 9.03% [intr{irq271: > igb1:que}] > 12 root=C2=A0 =C2=A0=C2=A0=C2=A0-92=C2=A0 =C2=A0 -=C2=A0 =C2=A0=C2=A0=C2=A00K=C2=A0=C2=A0=C2=A0448K CPU1=C2=A0 =C2=A0 1=C2=A0 59:09=C2=A0 8.94% [intr{irq265: > igb0:que}] > 12 root=C2=A0 =C2=A0=C2=A0=C2=A0-92=C2=A0 =C2=A0 -=C2=A0 =C2=A0=C2=A0=C2=A00K=C2=A0=C2=A0=C2=A0448K WAIT=C2=A0 =C2=A0 3=C2=A0 57:52=C2=A0 8.01% [intr{irq272: > igb1:que}] > 12 root=C2=A0 =C2=A0=C2=A0=C2=A0-92=C2=A0 =C2=A0 -=C2=A0 =C2=A0=C2=A0=C2=A00K=C2=A0=C2=A0=C2=A0448K WAIT=C2=A0 =C2=A0 1=C2=A0 59:32=C2=A0 7.96% [intr{irq270: > igb1:que}] > 12 root=C2=A0 =C2=A0=C2=A0=C2=A0-92=C2=A0 =C2=A0 -=C2=A0 =C2=A0=C2=A0=C2=A00K=C2=A0=C2=A0=C2=A0448K WAIT=C2=A0 =C2=A0 3=C2=A0 55:47=C2=A0 7.81% [intr{irq267: > igb0:que}] > 12 root=C2=A0 =C2=A0=C2=A0=C2=A0-92=C2=A0 =C2=A0 -=C2=A0 =C2=A0=C2=A0=C2=A00K=C2=A0=C2=A0=C2=A0448K WAIT=C2=A0 =C2=A0 0=C2=A0 55:24=C2=A0 7.23% [intr{irq264: > igb0:que}] > 12 root=C2=A0 =C2=A0=C2=A0=C2=A0-92=C2=A0 =C2=A0 -=C2=A0 =C2=A0=C2=A0=C2=A00K=C2=A0=C2=A0=C2=A0448K WAIT=C2=A0 =C2=A0 0=C2=A0 56:57=C2=A0 6.69% [intr{irq269: > igb1:que}] > 12 root=C2=A0 =C2=A0=C2=A0=C2=A0-92=C2=A0 =C2=A0 -=C2=A0 =C2=A0=C2=A0=C2=A00K=C2=A0=C2=A0=C2=A0448K WAIT=C2=A0 =C2=A0 3 203:34=C2=A0 4.74% [intr{irq275: > em1:rx 0}] > 0 root=C2=A0 =C2=A0=C2=A0=C2=A0-92=C2=A0 =C2=A0 0=C2=A0 =C2=A0=C2=A0=C2=A00K=C2=A0=C2=A0=C2=A0336K -=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A02 427:03=C2=A0 2.64% > [kernel{dummynet}] > 0 root=C2=A0 =C2=A0=C2=A0=C2=A0-92=C2=A0 =C2=A0 0=C2=A0 =C2=A0=C2=A0=C2=A00K=C2=A0=C2=A0=C2=A0336K -=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A03 206:57=C2=A0 2.54% [kernel{em0 > que}] > 86278 root=C2=A0 =C2=A0 =C2=A0 20=C2=A0 =C2=A0 0 33348K=C2=A0 8588K select=C2=A0 0=C2=A0=C2=A0=C2=A08:35=C2=A0 0.54% > /usr/local/sbin/snmpd -p /var/run/net_snmpd.pid -r > 12 root=C2=A0 =C2=A0=C2=A0=C2=A0-92=C2=A0 =C2=A0 -=C2=A0 =C2=A0=C2=A0=C2=A00K=C2=A0=C2=A0=C2=A0448K WAIT=C2=A0 =C2=A0 2=C2=A0=C2=A0=C2=A07:56=C2=A0 0.20% [intr{irq276: > em1:tx 0}] > > # cat /etc/sysctl.conf > dev.igb.0.rx_processing_limit=3D4096 > dev.igb.1.rx_processing_limit=3D4096 > dev.em.0.rx_int_delay=3D200 > dev.em.0.tx_int_delay=3D200 > dev.em.0.rx_abs_int_delay=3D4000 > dev.em.0.tx_abs_int_delay=3D4000 > dev.em.0.rx_processing_limit=3D4096 > dev.em.1.rx_int_delay=3D200 > dev.em.1.tx_int_delay=3D200 > dev.em.1.rx_abs_int_delay=3D4000 > dev.em.1.tx_abs_int_delay=3D4000 > dev.em.1.rx_processing_limit=3D4096 > net.inet.ip.forwarding=3D1 > net.inet.ip.fastforwarding=3D1 > net.inet.tcp.blackhole=3D2 > net.inet.udp.blackhole=3D0 > net.inet.ip.redirect=3D0 > net.inet.tcp.delayed_ack=3D0 > net.inet.tcp.recvbuf_max=3D4194304 > net.inet.tcp.sendbuf_max=3D4194304 > net.inet.tcp.sack.enable=3D0 > net.inet.tcp.drop_synfin=3D1 > net.inet.tcp.nolocaltimewait=3D1 > net.inet.ip.ttl=3D255 > net.inet.ip.sourceroute=3D0 > net.inet.ip.accept_sourceroute=3D0 > net.inet.udp.recvspace=3D64080 > net.inet.ip.rtmaxcache=3D1024 > net.inet.ip.intr_queue_maxlen=3D5120 > kern.ipc.nmbclusters=3D824288 > kern.ipc.maxsockbuf=3D83886080 > kern.ipc.maxsockets=3D102400 > net.inet.tcp.recvspace=3D95536 > net.inet.tcp.sendspace=3D95536 > net.local.stream.recvspace=3D32768 > net.local.stream.sendspace=3D32768 > kern.ipc.somaxconn=3D32768 > net.inet.tcp.maxtcptw=3D65535 > net.inet.ip.fw.one_pass=3D1 > net.inet.ip.fw.dyn_max=3D65535 > net.inet.ip.fw.dyn_buckets=3D2048 > net.inet.ip.fw.dyn_syn_lifetime=3D10 > net.inet.ip.fw.dyn_ack_lifetime=3D120 > net.inet.ip.fw.verbose=3D0 > net.inet.ip.dummynet.io_fast=3D1 > net.inet.ip.dummynet.hash_size=3D65536 > net.inet.ip.dummynet.pipe_slot_limit=3D1000 > net.inet.icmp.icmplim=3D3000 > net.inet.icmp.drop_redirect=3D1 > net.inet.icmp.log_redirect=3D0 > net.inet.icmp.bmcastecho=3D0 > net.inet.icmp.maskrepl=3D0 > kern.random.sys.harvest.ethernet=3D0 > kern.random.sys.harvest.point_to_point=3D0 > kern.random.sys.harvest.interrupt=3D0 > net.inet.raw.maxdgram=3D16384 > net.inet.raw.recvspace=3D16384 > net.route.netisr_maxqlen=3D8192 > net.inet.ip.intr_queue_maxlen=3D10240 > net.isr.dispatch=3Ddeferred > > # cat /boot/loader.conf > loader_logo=3D"beastie" > autoboot_delay=3D3 > geom_mirror_load=3D"YES" > hw.igb.rxd=3D4096 > hw.igb.txd=3D4096 > hw.igb.rx_process_limit=3D4096 > hw.igb.max_interrupt_rate=3D32000 > hw.igb.num_queues=3D4 > hw.igb.fc_setting=3D0 > hw.igb.lro=3D0 > hw.em.rxd=3D4096 > hw.em.txd=3D4096 > hw.em.rx_process_limit=3D4096 > hw.em.fc_setting=3D0 > dev.em.0.rx_int_delay=3D200 > dev.em.0.tx_int_delay=3D200 > dev.em.0.rx_abs_int_delay=3D4000 > dev.em.0.tx_abs_int_delay=3D4000 > dev.em.1.rx_int_delay=3D200 > dev.em.1.tx_int_delay=3D200 > dev.em.1.rx_abs_int_delay=3D4000 > dev.em.1.tx_abs_int_delay=3D4000 > net.isr.maxthreads=3D4 > net.isr.bindthreads=3D0 > net.inet.tcp.tcbhashsize=3D32000 > net.link.ifqmaxlen=3D10240 > net.isr.defaultqlimit=3D8192 > > # vmstat -i > interrupt=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 total=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0rate > irq20: ehci1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A04171628=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 > irq21: atapci0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A01561194=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 > irq22: ehci0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2713150=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 > cpu0:timer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A014622957598=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A08082 > irq264: igb0:que 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0515616328=C2=A0 =C2=A0 =C2=A0 =C2=A0 284 > irq265: igb0:que 1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0738456087=C2=A0 =C2=A0 =C2=A0 =C2=A0 408 > irq266: igb0:que 2=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0711371660=C2=A0 =C2=A0 =C2=A0 =C2=A0 393 > irq267: igb0:que 3=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0462738813=C2=A0 =C2=A0 =C2=A0 =C2=A0 255 > irq268: igb0:link=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 > irq269: igb1:que 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0656044816=C2=A0 =C2=A0 =C2=A0 =C2=A0 362 > irq270: igb1:que 1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0546931002=C2=A0 =C2=A0 =C2=A0 =C2=A0 302 > irq271: igb1:que 2=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0617173223=C2=A0 =C2=A0 =C2=A0 =C2=A0 341 > irq272: igb1:que 3=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0644295672=C2=A0 =C2=A0 =C2=A0 =C2=A0 356 > irq273: igb1:link=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 > irq274: em0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 557400132=C2=A0 =C2=A0 =C2=A0 =C2=A0 308 > irq275: em1:rx 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0424252744=C2=A0 =C2=A0 =C2=A0 =C2=A0 234 > irq276: em1:tx 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0708469817=C2=A0 =C2=A0 =C2=A0 =C2=A0 391 > irq277: em1:link=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 > cpu3:timer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0678408141=C2=A0 =C2=A0 =C2=A0 =C2=A0 374 > cpu1:timer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0674674076=C2=A0 =C2=A0 =C2=A0 =C2=A0 372 > cpu2:timer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0621495291=C2=A0 =C2=A0 =C2=A0 =C2=A0 343 > Total=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 23188731381=C2=A0 =C2=A0 =C2=A0 12816 > > # netstat -w1 > input=C2=A0 =C2=A0 =C2=A0 =C2=A0 (Total)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0output > packets=C2=A0 errs idrops=C2=A0 =C2=A0 =C2=A0 bytes=C2=A0 =C2=A0 packets=C2=A0 errs=C2=A0 =C2=A0 =C2=A0 bytes colls > 442k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0304M=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0457k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0393M=C2=A0 =C2=A0=C2=A0=C2=A00 > 449k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0308M=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0463k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0395M=C2=A0 =C2=A0=C2=A0=C2=A00 > 445k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0304M=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0461k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0393M=C2=A0 =C2=A0=C2=A0=C2=A00 > 439k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0303M=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0456k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0393M=C2=A0 =C2=A0=C2=A0=C2=A00 > 434k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0297M=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0450k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0387M=C2=A0 =C2=A0=C2=A0=C2=A00 > 440k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0301M=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0456k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0392M=C2=A0 =C2=A0=C2=A0=C2=A00 > 438k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0300M=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0455k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0391M=C2=A0 =C2=A0=C2=A0=C2=A00 > > # ifconfig lagg0=C2=A0=C2=A0=C2=A0(internal, 500 VLAN's) > lagg0: flags=3D8843 metric 0 mtu > 1500 > options=3D401bb > ether a0:36:9f:16:d0:9c > media: Ethernet autoselect > status: active > laggproto lacp lagghash l2,l3,l4 > laggport: igb1 flags=3D1c > laggport: igb0 flags=3D1c > > # ifconfig lagg1=C2=A0 =C2=A0 - (external, NAT) > lagg1: flags=3D8843 metric 0 mtu > 1500 > options=3D4209b > ether 00:1e:67:59:ea:89 > inet =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.14 netmask= 0xffffffe0 broadcast > =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.31 > inet =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.70 netmask= 0xffffffff broadcast > =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.70 > inet =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.71 netmask= 0xffffffff broadcast > =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.71 > inet =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.72 netmask= 0xffffffff broadcast > =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.72 > inet =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.73 netmask= 0xffffffff broadcast > =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.73 > inet =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.74 netmask= 0xffffffff broadcast > =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.74 > inet =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.75 netmask= 0xffffffff broadcast > =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.75 > inet =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.76 netmask= 0xffffffff broadcast > =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.76 > inet =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.77 netmask= 0xffffffff broadcast > =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.77 > inet =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.78 netmask= 0xffffffff broadcast > =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.78 > inet =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.79 netmask= 0xffffffff broadcast > =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.79 > inet =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.33 netmask= 0xfffffff0 broadcast > =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.47 > media: Ethernet autoselect > status: active > laggproto lacp lagghash l2,l3,l4 > laggport: em1 flags=3D1c > laggport: em0 flags=3D1c > > # netstat -w1 -I em0 > input=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (em0)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0output > packets=C2=A0 errs idrops=C2=A0 =C2=A0 =C2=A0 bytes=C2=A0 =C2=A0 packets=C2=A0 errs=C2=A0 =C2=A0 =C2=A0 bytes colls > 101k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0111M=C2=A0 =C2=A0 =C2=A0 =C2=A0 36k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 13M=C2=A0 =C2=A0=C2=A0=C2=A00 > 101k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0112M=C2=A0 =C2=A0 =C2=A0 =C2=A0 36k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 13M=C2=A0 =C2=A0=C2=A0=C2=A00 > 100k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0112M=C2=A0 =C2=A0 =C2=A0 =C2=A0 37k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 13M=C2=A0 =C2=A0=C2=A0=C2=A00 > > # netstat -w1 -I em1 > [code]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 input=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (em1)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0output > packets=C2=A0 errs idrops=C2=A0 =C2=A0 =C2=A0 bytes=C2=A0 =C2=A0 packets=C2=A0 errs=C2=A0 =C2=A0 =C2=A0 bytes colls > 100k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0111M=C2=A0 =C2=A0 =C2=A0 =C2=A0 37k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A09.1M=C2=A0 =C2=A0=C2=A0=C2=A00 > 102k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0113M=C2=A0 =C2=A0 =C2=A0 =C2=A0 39k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 10M=C2=A0 =C2=A0=C2=A0=C2=A00 > 91k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0101M=C2=A0 =C2=A0 =C2=A0 =C2=A0 38k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A09.7M=C2=A0 =C2=A0=C2=A0=C2=A00 > > # netstat -w1 -I igb0 > input=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0(igb0)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0output > packets=C2=A0 errs idrops=C2=A0 =C2=A0 =C2=A0 bytes=C2=A0 =C2=A0 packets=C2=A0 errs=C2=A0 =C2=A0 =C2=A0 bytes colls > 39k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A09.1M=C2=A0 =C2=A0 =C2=A0 =C2=A0 51k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 57M=C2=A0 =C2=A0=C2=A0=C2=A00 > 38k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A09.1M=C2=A0 =C2=A0 =C2=A0 =C2=A0 49k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 54M=C2=A0 =C2=A0=C2=A0=C2=A00 > 39k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A09.4M=C2=A0 =C2=A0 =C2=A0 =C2=A0 51k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 56M=C2=A0 =C2=A0=C2=A0=C2=A00 > > # netstat -w1 -I igb1 > input=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0(igb1)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0output > packets=C2=A0 errs idrops=C2=A0 =C2=A0 =C2=A0 bytes=C2=A0 =C2=A0 packets=C2=A0 errs=C2=A0 =C2=A0 =C2=A0 bytes colls > 36k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 14M=C2=A0 =C2=A0 =C2=A0 =C2=A0 48k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 56M=C2=A0 =C2=A0=C2=A0=C2=A00 > 35k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 14M=C2=A0 =C2=A0 =C2=A0 =C2=A0 50k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 59M=C2=A0 =C2=A0=C2=A0=C2=A00 > 34k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 13M=C2=A0 =C2=A0 =C2=A0 =C2=A0 48k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 57M=C2=A0 =C2=A0=C2=A0=C2=A00 > > # netstat -w1 -I lagg0 > input=C2=A0 =C2=A0 =C2=A0 =C2=A0 (lagg0)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0output > packets=C2=A0 errs idrops=C2=A0 =C2=A0 =C2=A0 bytes=C2=A0 =C2=A0 packets=C2=A0 errs=C2=A0 =C2=A0 =C2=A0 bytes colls > 75k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 23M=C2=A0 =C2=A0 =C2=A0 =C2=A0 98k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0113M=C2=A0 =C2=A0=C2=A0=C2=A00 > 73k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 21M=C2=A0 =C2=A0 =C2=A0 =C2=A0 98k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0113M=C2=A0 =C2=A0=C2=A0=C2=A00 > 73k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 23M=C2=A0 =C2=A0 =C2=A0 =C2=A0 98k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0112M=C2=A0 =C2=A0=C2=A0=C2=A00 > > # netstat -w1 -I lagg1 > input=C2=A0 =C2=A0 =C2=A0 =C2=A0 (lagg1)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0output > packets=C2=A0 errs idrops=C2=A0 =C2=A0 =C2=A0 bytes=C2=A0 =C2=A0 packets=C2=A0 errs=C2=A0 =C2=A0 =C2=A0 bytes colls > 100k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0112M=C2=A0 =C2=A0 =C2=A0 =C2=A0 74k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 24M=C2=A0 =C2=A0=C2=A0=C2=A00 > 101k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0113M=C2=A0 =C2=A0 =C2=A0 =C2=A0 73k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 24M=C2=A0 =C2=A0=C2=A0=C2=A00 > 102k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0114M=C2=A0 =C2=A0 =C2=A0 =C2=A0 74k=C2=A0 =C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 24M=C2=A0 =C2=A0=C2=A0=C2=A00 > >> > _______________________________________________ >=C2=A0=C2=A0=C2=A0freebsd-net@freebsd.org=C2=A0=C2=A0=C2=A0mailing list >=C2=A0=C2=A0=C2=A0http://lists.freebsd.org/mailman/listinfo/freebsd-net= =C2=A0 > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" _______________________________________________=C2=A0 freebsd-net@freebsd.= org=C2=A0=C2=A0=C2=A0mailing list=C2=A0 http://lists.freebsd.org/mailman/listinfo/freebsd-net=C2=A0 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 Sun Jul 14 17:17:48 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 80A4F9EB for ; Sun, 14 Jul 2013 17:17:48 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id CAAACA09 for ; Sun, 14 Jul 2013 17:17:47 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.7/8.14.7) with ESMTP id r6EHHj8k014401; Mon, 15 Jul 2013 00:17:45 +0700 (NOVT) (envelope-from eugen@grosbein.net) Message-ID: <51E2DD34.3040006@grosbein.net> Date: Mon, 15 Jul 2013 00:17:40 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: Barney Cordoba Subject: Re: FreeBSD router problems References: <1373818461.35904.YahooMailBasic@web121605.mail.ne1.yahoo.com> In-Reply-To: <1373818461.35904.YahooMailBasic@web121605.mail.ne1.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, isp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jul 2013 17:17:48 -0000 On 14.07.2013 23:14, Barney Cordoba wrote: > So why not get a real 10gb/s card? RJ45 10gig is here, > and it works a lot better than LAGG. > > If you want to get more than 1Gb/s on a single connection, > you'd need to use roundrobin, which will alternate packets > without concern for ordering. Purists will argue against it, > but it does work and modern TCP stacks know how to deal > with out of order packets. Except of FreeBSD's packet reassembly is broken for long time. For example, http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/167603 From owner-freebsd-net@FreeBSD.ORG Sun Jul 14 19:52:42 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2C763BDB for ; Sun, 14 Jul 2013 19:52:42 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id CBD2111E for ; Sun, 14 Jul 2013 19:52:41 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 608145CE7B; Sun, 14 Jul 2013 21:52:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id bKJyTQPZGOTW; Sun, 14 Jul 2013 21:52:39 +0200 (CEST) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 7B76C5CE76; Sun, 14 Jul 2013 21:52:39 +0200 (CEST) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.incore (Postfix) with ESMTP id 1B68C50861; Sun, 14 Jul 2013 21:52:39 +0200 (CEST) Message-ID: <51E30186.9050707@incore.de> Date: Sun, 14 Jul 2013 21:52:38 +0200 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: pyunyh@gmail.com Subject: Re: sis(4) flow control References: <51DC1599.8040805@incore.de> <20130710023512.GB2753@michelle.cdnetworks.com> <51DDDDAB.6070100@incore.de> <20130711002557.GA6697@michelle.cdnetworks.com> <51E1B8F0.5030100@incore.de> <20130714100347.GA1105@michelle.cdnetworks.com> In-Reply-To: <20130714100347.GA1105@michelle.cdnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jul 2013 19:52:42 -0000 Yonghyeon PYUN wrote: >> Maybe there is a bug in vr(4) that generates the hang, but why is > > Probably yes and I shall have to narrow down the issue. One more hint: No hang - but of course no TX support - anymore, when I use --- if_vr.c.orig 2013-06-25 09:58:29.000000000 +0200 +++ if_vr.c 2013-07-14 18:09:12.000000000 +0200 @@ -351,7 +351,6 @@ fc |= VR_FLOWCR1_RXPAUSE; if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_TXPAUSE) != 0) { - fc |= VR_FLOWCR1_TXPAUSE; sc->vr_flags |= VR_F_TXPAUSE; } CSR_WRITE_1(sc, VR_FLOWCR1, fc); Probably the RX pause frames will work with this patch. >> negotiation of flowcontrol on vr(4) not done at boot time as shown for >> msk(4) ? >> > > msk(4) supported flow-control from day 1 with a hack and it was > re-implemented later with proper way such that it always announces > flow-control. However for other drivers(i.e vr(4)) that didn't > support the feature in the beginning, you have to explicitly enable > the feature. The decision was made to provide compatibility and to > not introduce POLA. Thanks for clarification, I see the flag MIIF_FORCEPAUSE does the job. >> If you need more information about the hang let me know. > > I guess it would be good idea to use a link partner that shows > hardware MAC statistics. If your switch provides such information > that's fine. If you use direct connection between two hosts without > switch, use other network drivers(most gigabit controllers support > hardware MAC counters). I can easy realize to use my laptop with msk(4) as a link partner for my soekris box with vr(4). -- Dr. Andreas Longwitz From owner-freebsd-net@FreeBSD.ORG Mon Jul 15 00:44:06 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0C3559D9; Mon, 15 Jul 2013 00:44:06 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by mx1.freebsd.org (Postfix) with ESMTP id D7700B08; Mon, 15 Jul 2013 00:44:05 +0000 (UTC) Received: by mail-pd0-f171.google.com with SMTP id y14so10150272pdi.30 for ; Sun, 14 Jul 2013 17:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=6Pql4np+ldehWWnUDhe0exSDRGCzmJ3rWkWJFbG+2fs=; b=jBkCdEX48PpjCpB51SWiWTGOq96prmQwefX65S+504BMbqtZXt7y5BVgws2jVbTJyr VTOH+79zpMKXvnVkJ2jbxD4EQeljta3nZAJAHVI2/AWPxLn5ZJG1RzPsdi7k/4Tq5FKP RVoH5PamTwWwv8Uw90pVhpEZuIza3eEmKYUvihpjw939mers1qAXi7ggk7tTzyF3xLGD nMpZc9BLhb3xBlIxvQ5e5WYyeUuUkiRMP8Mgq0kWFKEfm9tTbDy9xJE9mKxCY+wGSLlP KlKzZI+zIkio5CpiiG8zfmgVJ+ydb52moUl9Yta3xx7x4hvDYeJ7T3pAR8AtnStJHV4y VS4g== X-Received: by 10.66.148.41 with SMTP id tp9mr53538272pab.40.1373849045617; Sun, 14 Jul 2013 17:44:05 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id eg3sm61132475pac.1.2013.07.14.17.44.02 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 14 Jul 2013 17:44:04 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 15 Jul 2013 09:43:58 +0900 From: Yonghyeon PYUN Date: Mon, 15 Jul 2013 09:43:58 +0900 To: claudiu vasadi Subject: Re: kern/180382: [ae] kernel: ae0: watchdog timeout - resetting. Message-ID: <20130715004358.GA2959@michelle.cdnetworks.com> References: <201307091122.r69BM9Ev053001@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, yongari@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 00:44:06 -0000 On Sun, Jul 14, 2013 at 04:20:30PM +0200, claudiu vasadi wrote: > Hi, > > The patch applied without any problems and the "Size mismatch" messages > are gone now. However, we cannot get an IP via "dhclient" and we also > don't have any network connectivity if we set a manual IP. The only > messages we see now (with the manual IP) is "no buffer space available". > I checked the Ip, netmask, gateway and mbufs but they all seem to be ok. > "ifconfg ae0 down && ifconfig ae0 up" does not fix the problem. We also > tried a reboot but again, it did not fix the problem. We have no ping or > anything. > > No other error messages were observed. > > PS: Sorry for the late reply but the machine is on a remote site. > PS2: I can arrange a ssh account if this would help you. > Sorry, I couldn't test the patch due to lack of access to the L2 hardware. Actually there was a typo such that driver thought it had no link at all. I've updated diff(URL is the same) so please try again. From owner-freebsd-net@FreeBSD.ORG Mon Jul 15 02:38:01 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8225A5AF for ; Mon, 15 Jul 2013 02:38:01 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by mx1.freebsd.org (Postfix) with ESMTP id 10BA013B for ; Mon, 15 Jul 2013 02:38:00 +0000 (UTC) Received: by mail-lb0-f181.google.com with SMTP id w10so8867885lbi.26 for ; Sun, 14 Jul 2013 19:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/CxRIW9bl+zq2vj3T6D2V0WxgvztJLQU8hJ7b4NuZl8=; b=vJb7T//LwtKk0sgOUZt4G5cc9vUF65RcSblKOs/3LrwtXaijJOrzB9Ckr4gHmX1XrR bg4M6PpZCSw7VWNL8ryeSPxuk2RiDfTPyOgkjif5+7eNPyV7ryHmxrgTBw4FP/qWRl0j BMW8lJWu/CkLDhH1Qk92iqdioerI9ojry99Tbtidr5w5amD8pLldTrURop9SEWxFO1Z1 OYMW+4YnXUwGqTa0fLYi/Q1okNdhiyeej2Tlt50yqgN38DtNNvVU4Oj2DytXBONNx8qp zU6scDNAj30A/6iUh+ixOnqCIzU5tFK9J4E3kn3B4DXQDSbRbUliMouu26aas/zzRqiX 1czw== MIME-Version: 1.0 X-Received: by 10.112.125.199 with SMTP id ms7mr23367344lbb.29.1373855879892; Sun, 14 Jul 2013 19:37:59 -0700 (PDT) Received: by 10.114.184.41 with HTTP; Sun, 14 Jul 2013 19:37:59 -0700 (PDT) In-Reply-To: <51E0E2AF.7090404@mail.ru> References: <51E0E2AF.7090404@mail.ru> Date: Mon, 15 Jul 2013 10:37:59 +0800 Message-ID: Subject: Re: SO_REUSEPORT: strange kernel balancer behaviour From: Sepherosa Ziehau To: trafdev Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 02:38:01 -0000 On Sat, Jul 13, 2013 at 1:16 PM, trafdev wrote: > Hello. > > Could someone help with following problem of SO_REUSEPORT. The most portable "load balance" between processes listening on the same TCP addr/port probably is: s=socket(); bind(s); listen(s); /* various socketopt and fcntl as you needed */ pid=fork(); if (pid==0) { server_loop(s); exit(1); } server_loop(s); exit(1); Even in Linux or DragonFly SO_REUSEPORT "load balance" between processes listening on the same TCP addr/port was introduced recently, so you probably won't want to rely on it. Best Regards, sephe -- Tomorrow Will Never Die From owner-freebsd-net@FreeBSD.ORG Mon Jul 15 06:47:36 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C6FC5DED for ; Mon, 15 Jul 2013 06:47:36 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id A0D09C14 for ; Mon, 15 Jul 2013 06:47:36 +0000 (UTC) Received: by mail-pb0-f53.google.com with SMTP id xb12so10938830pbc.26 for ; Sun, 14 Jul 2013 23:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=PaTjONhsniBy8BBwXY8xqCZqWtSvfZXIEOoKJpTcm/4=; b=hZPSZ+o+TxjC5f2/ywdVpulfAOz4MWZlRpDWldYb+JEjzKbm7y3BaHxEc+V6jqzTrm GMkdZLkh5S3Q86bRSeSIBwJeKAFCgNtnVWYmS3DyQk737csZe0JF/W1VmIhgnyBQIFk2 Z2yQj5CvtJ7vvG3ibwX2D6q1cbuBAmEK6fYh+vNBTOWToiZnYf0glogcaYX7oMI7jg+K dAxzS5/nmSa9Rld4bNjBRnqZjft5V4nv5T4PppE4c644X6uoXtybljeQgki0zbf6qpZK uDPXP7OGHMJ7gK0e9JO0ftp4KrkN8oL8uL/SQgLXJi2+i3j+2SDqrEg97owjtAZpZab4 hbTA== X-Received: by 10.66.2.130 with SMTP id 2mr53866577pau.13.1373870856425; Sun, 14 Jul 2013 23:47:36 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id re16sm62666474pac.16.2013.07.14.23.47.33 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 14 Jul 2013 23:47:35 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 15 Jul 2013 15:47:31 +0900 From: Yonghyeon PYUN Date: Mon, 15 Jul 2013 15:47:30 +0900 To: Andreas Longwitz Subject: Re: sis(4) flow control Message-ID: <20130715064730.GA1088@michelle.cdnetworks.com> References: <51DC1599.8040805@incore.de> <20130710023512.GB2753@michelle.cdnetworks.com> <51DDDDAB.6070100@incore.de> <20130711002557.GA6697@michelle.cdnetworks.com> <51E1B8F0.5030100@incore.de> <20130714100347.GA1105@michelle.cdnetworks.com> <51E30186.9050707@incore.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51E30186.9050707@incore.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 06:47:36 -0000 On Sun, Jul 14, 2013 at 09:52:38PM +0200, Andreas Longwitz wrote: > Yonghyeon PYUN wrote: > > >> Maybe there is a bug in vr(4) that generates the hang, but why is > > > > Probably yes and I shall have to narrow down the issue. > > One more hint: No hang - but of course no TX support - anymore, when I use > > --- if_vr.c.orig 2013-06-25 09:58:29.000000000 +0200 > +++ if_vr.c 2013-07-14 18:09:12.000000000 +0200 > @@ -351,7 +351,6 @@ > fc |= VR_FLOWCR1_RXPAUSE; > if ((IFM_OPTIONS(mii->mii_media_active) & > IFM_ETH_TXPAUSE) != 0) { > - fc |= VR_FLOWCR1_TXPAUSE; > sc->vr_flags |= VR_F_TXPAUSE; > } > CSR_WRITE_1(sc, VR_FLOWCR1, fc); > > Probably the RX pause frames will work with this patch. Yes but it also disables generating TX pause frames. The controller is not smart enough to know how many number of RX buffers are available so driver has to explicitly tell the amount of free RX buffers. It seems the logic has a bug. > > >> negotiation of flowcontrol on vr(4) not done at boot time as shown for > >> msk(4) ? > >> > > > > msk(4) supported flow-control from day 1 with a hack and it was > > re-implemented later with proper way such that it always announces > > flow-control. However for other drivers(i.e vr(4)) that didn't > > support the feature in the beginning, you have to explicitly enable > > the feature. The decision was made to provide compatibility and to > > not introduce POLA. > > Thanks for clarification, I see the flag MIIF_FORCEPAUSE does the job. > > >> If you need more information about the hang let me know. > > > > I guess it would be good idea to use a link partner that shows > > hardware MAC statistics. If your switch provides such information > > that's fine. If you use direct connection between two hosts without > > switch, use other network drivers(most gigabit controllers support > > hardware MAC counters). > > I can easy realize to use my laptop with msk(4) as a link partner for my > soekris box with vr(4). > > -- > Dr. Andreas Longwitz > From owner-freebsd-net@FreeBSD.ORG Mon Jul 15 11:06:47 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9B303F79 for ; Mon, 15 Jul 2013 11:06:47 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 8EB82FC9 for ; Mon, 15 Jul 2013 11:06:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6FB6lpE084516 for ; Mon, 15 Jul 2013 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6FB6l0r084513 for freebsd-net@FreeBSD.org; Mon, 15 Jul 2013 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 15 Jul 2013 11:06:47 GMT Message-Id: <201307151106.r6FB6l0r084513@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 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 11:06:47 -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 -------------------------------------------------------------------------------- s kern/180468 net [request] LOCAL_PEERCRED support for PF_INET o kern/180430 net [ofed] [patch] Bad UDP checksum calc for fragmented pa o kern/180065 net [netinet6] [patch] Multicast loopback to own host brok p kern/179975 net [igb] igb(4) fails to do polling(4) o kern/179926 net [lacp] [patch] active aggregator selection bug o kern/179824 net [ixgbe] System (9.1-p4) hangs on heavy ixgbe network t o kern/179733 net [lagg] [patch] interface loses capabilities when proto o kern/179429 net [tap] STP enabled tap bridge o kern/179299 net [igb] Intel X540-T2 - unstable driver a kern/179264 net [vimage] [pf] Core dump with Packet filter and VIMAGE o kern/178947 net [arp] arp rejecting not working o kern/178782 net [ixgbe] 82599EB SFP does not work with passthrough und o kern/178612 net [run] kernel panic due the problems with run driver o kern/178472 net [ip6] [patch] make return code consistent with IPv4 co o kern/178079 net [tcp] Switching TCP CC algorithm panics on sparc64 wit s kern/178071 net FreeBSD unable to recongize Kontron (Industrial Comput o kern/177905 net [xl] [panic] ifmedia_set when pluging CardBus LAN card o kern/177618 net [bridge] Problem with bridge firewall with trunk ports o kern/177417 net [ip6] Invalid protocol value in ipsec6_common_input_cb o kern/177402 net [igb] [pf] problem with ethernet driver igb + pf / alt o kern/177400 net [jme] JMC25x 1000baseT establishment issues o kern/177366 net [ieee80211] negative malloc(9) statistics for 80211nod f kern/177362 net [netinet] [patch] Wrong control used to return TOS o kern/177194 net [netgraph] Unnamed netgraph nodes for vlan interfaces o kern/177139 net [igb] igb drops ethernet ports 2 and 3 o kern/176884 net [re] re0 flapping up/down o kern/176671 net [epair] MAC address for epair device not unique o kern/176484 net [ipsec] [enc] [patch] panic: IPsec + enc(4); device na o kern/176446 net [netinet] [patch] Concurrency in ixgbe driving out-of- o kern/176420 net [kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net [kernel] [patch] socketpair support for LOCAL_PEERCRED o kern/176401 net [netgraph] page fault in netgraph o kern/176167 net [ipsec][lagg] using lagg and ipsec causes immediate pa o kern/176097 net [lagg] [patch] lagg/lacp broken when aggregated interf o kern/176027 net [em] [patch] flow control systcl consistency for em dr o kern/176026 net [tcp] [patch] TCP wrappers caused quite a lot of warni o bin/175974 net ppp(8): logic issue o kern/175864 net [re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net [amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 net no ethernet detected on system with EG20T PCH chipset o kern/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173871 net [gif] process of 'ifconfig gif0 create hangs' when if_ o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171739 net [bce] [panic] bce related kernel panic o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis p kern/165903 net mbuf leak o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS 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/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi 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/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/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/155680 net [multicast] problems with multicast s kern/155642 net [new driver] [request] Add driver for Realtek RTL8191S o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [new driver] [request]: Port brcm80211 driver from Lin 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 p 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 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/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 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 kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference 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 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/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 f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg 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/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f 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/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/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/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 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 kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb 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 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/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/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 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 f 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/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy 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/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/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 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/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work 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/121534 net [ipl] [nat] FreeBSD Release 6.3 Kernel Trap 12: 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 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/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands 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 bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] f kern/108197 net [panic] [gif] [ip6] if_delmulti reference counting pan 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/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/104738 net [inet] [patch] Reentrant problem with inet_ntoa in the 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/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling 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 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge 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/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ 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/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/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/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 o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w 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 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 452 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jul 15 13:03:27 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C9AD2D7; Mon, 15 Jul 2013 13:03:27 +0000 (UTC) (envelope-from oshogbo.vx@gmail.com) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id 89675968; Mon, 15 Jul 2013 13:03:27 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id 10so25652522ied.14 for ; Mon, 15 Jul 2013 06:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=64Z5T4A2R8Dm63YuwfCC3nv754OMoEFtx0yzbtGhbTQ=; b=pOtLTw9Ckrwc0GT7n9b6wwL9/FFIdPkNXM8J8C1r8mL10222BucsymzbDwNMxajW4D lnEObjovrhHom7904WZZyRnSN347haE++PNeVGBDg6+P6sK4zL7oIQqtjjtmJwd6BW+C n6UCdQCDIqRlnk77IyBVpWKgBXL5qDbmhD7NMKJLWKwdn0HrRxMnkezBvjyK0K58/9Lk S534ekkV953J9TJ+ugpI42rJ2koJJtZDnFd1xEtgXWZAofLb6WtbdLHYLjUZXq3LQ6Lb UIqDlWY3wdiiukIyl/hGfbmg1U5OCAQIa4Qutw2UJysMDQJkQphOG7DhBD8sreuoatwX /4SQ== MIME-Version: 1.0 X-Received: by 10.42.202.144 with SMTP id fe16mr17567450icb.72.1373893407134; Mon, 15 Jul 2013 06:03:27 -0700 (PDT) Sender: oshogbo.vx@gmail.com Received: by 10.50.147.72 with HTTP; Mon, 15 Jul 2013 06:03:27 -0700 (PDT) Date: Mon, 15 Jul 2013 15:03:27 +0200 X-Google-Sender-Auth: j7nIElG8MOe8AbK634bMO7cT3lA Message-ID: Subject: soreceive_generic and soreceive_dgram error checking From: Mario Oshogbo To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary=20cf301af5c57ddfc904e18c7ccb Cc: mjguzik@gmail.com, andre@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 13:03:28 -0000 --20cf301af5c57ddfc904e18c7ccb Content-Type: text/plain; charset=ISO-8859-1 Hi, I'm a student working in GSoC project. My task on this summer is to write some new features for capsicum framework. Currently I working on writing two new rights (CAP_SEND_RIGHTS and CAP_RECV_RIGHTS). I have some questions about error checking in the soreceive_generic and the soreceive_dgram. I noticed that after calling dom_externalize function there was no explicit error checks. After code analysis of soreceive_generic is likely that error will be returned property. But still, are we need some more things to do after calling dom_externalize or we could simply jump to the release if we got some error from that function? The more puzzling situation is with sorecive_dgram. After calling dom_externalize we don't check the error anywhere. We also don't return the error on the end of the function. Even if we change "return 0" to the "return error" there is still the chance that error will be override by other function (like uimove). Its there any contraindications to add after calling dom_externalize simply check returned value and handle error? I also attach diff with my proposal of error checking in both functions. Should we apply it for both function or we should only change soreceive_dgram or ma by none? Should we make some other changes in soreceive_dgram? I will be very grateful for any help, oshogbo --20cf301af5c57ddfc904e18c7ccb Content-Type: application/octet-stream; name="uipc_socket.diff" Content-Disposition: attachment; filename="uipc_socket.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hj5og57s0 LS0tIHVpcGNfc29ja2V0LmMJMjAxMy0wNi0yOCAxMToxNDoyMi4wMDAwMDAwMDAgKzAyMDAKKysr IHVpcGNfc29ja2V0LmMJMjAxMy0wNy0xNSAxNDo1MzoxNS4wMDAwMDAwMDAgKzAyMDAKQEAgLTE3 MjgsNiArMTcyOCw4IEBAIGRvbnRibG9jazoKIAkJCQlWTkVUX1NPX0FTU0VSVChzbyk7CiAJCQkJ ZXJyb3IgPSAoKnByLT5wcl9kb21haW4tPmRvbV9leHRlcm5hbGl6ZSkKIAkJCQkgICAgKGNtLCBj b250cm9scCwgZmxhZ3MpOworCQkJCWlmIChlcnJvciAhPSAwKQorCQkJCQlnb3RvIHJlbGVhc2U7 CiAJCQkJU09DS0JVRl9MT0NLKCZzby0+c29fcmN2KTsKIAkJCX0gZWxzZSBpZiAoY29udHJvbHAg IT0gTlVMTCkKIAkJCQkqY29udHJvbHAgPSBjbTsKQEAgLTIzNjMsNiArMjM2NSwxMCBAQCBzb3Jl Y2VpdmVfZGdyYW0oc3RydWN0IHNvY2tldCAqc28sIHN0cnVjCiAJCQlpZiAocHItPnByX2RvbWFp bi0+ZG9tX2V4dGVybmFsaXplICE9IE5VTEwpIHsKIAkJCQllcnJvciA9ICgqcHItPnByX2RvbWFp bi0+ZG9tX2V4dGVybmFsaXplKQogCQkJCSAgICAoY20sIGNvbnRyb2xwLCBmbGFncyk7CisJCQkJ aWYgKGVycm9yICE9IDApIHsKKwkJCQkJbV9mcmVlbShtKTsKKwkJCQkJcmV0dXJuIChlcnJvcik7 CisJCQkJfQogCQkJfSBlbHNlIGlmIChjb250cm9scCAhPSBOVUxMKQogCQkJCSpjb250cm9scCA9 IGNtOwogCQkJZWxzZQo= --20cf301af5c57ddfc904e18c7ccb-- From owner-freebsd-net@FreeBSD.ORG Mon Jul 15 13:06:18 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0492A1D9; Mon, 15 Jul 2013 13:06:18 +0000 (UTC) (envelope-from claudiu.vasadi@gmail.com) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by mx1.freebsd.org (Postfix) with ESMTP id C59FF9A4; Mon, 15 Jul 2013 13:06:17 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id c10so26400717ieb.10 for ; Mon, 15 Jul 2013 06:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nZ1ElVBPea0oAuVfKUP9mqfWbL1LqHc9OOhBIZmptsc=; b=zcuxpG0ZYqk/mcYzI2Ewa+d/D++0j7OeB0d6J72KRKSP5qouDI7o+1XhENgm0fQOsG TV1Put0D8eGQ1yqaNKbJMhRFrYiwDAL1ZjTYVwQDdSUhyNchNstGpGXe3467o1YXP729 g7GslHTnMQioXR6MW7bADx6LXN0s8emjSVxT3kUJDDw/rJXtwY+oRYpfPbdtNocJ37b0 0i2Bcty+LvYBcFynfdR7IGORCLXl5w6abl7E8w2eNpmm1thlZucOCxAaaIIb+yHnCck4 /d7oxicDVSuXMucehFokvg1twN8FGXX/U/dWH8flVTveV3FkX6pBC2lLaUE4mHJG+EwI E6Fg== MIME-Version: 1.0 X-Received: by 10.43.84.131 with SMTP id ak3mr17275089icc.84.1373893577291; Mon, 15 Jul 2013 06:06:17 -0700 (PDT) Received: by 10.64.56.67 with HTTP; Mon, 15 Jul 2013 06:06:17 -0700 (PDT) In-Reply-To: <20130715004358.GA2959@michelle.cdnetworks.com> References: <201307091122.r69BM9Ev053001@freefall.freebsd.org> <20130715004358.GA2959@michelle.cdnetworks.com> Date: Mon, 15 Jul 2013 15:06:17 +0200 Message-ID: Subject: Re: kern/180382: [ae] kernel: ae0: watchdog timeout - resetting. From: claudiu vasadi To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org, yongari@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 13:06:18 -0000 Hi, Quick update: works now. Will let you know if it continues like this or if we hit another problem. Huge thanks for the patch. On Mon, Jul 15, 2013 at 2:43 AM, Yonghyeon PYUN wrote: > On Sun, Jul 14, 2013 at 04:20:30PM +0200, claudiu vasadi wrote: > > Hi, > > > > The patch applied without any problems and the "Size mismatch" messages > > are gone now. However, we cannot get an IP via "dhclient" and we also > > don't have any network connectivity if we set a manual IP. The only > > messages we see now (with the manual IP) is "no buffer space available". > > I checked the Ip, netmask, gateway and mbufs but they all seem to be ok. > > "ifconfg ae0 down && ifconfig ae0 up" does not fix the problem. We also > > tried a reboot but again, it did not fix the problem. We have no ping or > > anything. > > > > No other error messages were observed. > > > > PS: Sorry for the late reply but the machine is on a remote site. > > PS2: I can arrange a ssh account if this would help you. > > > > Sorry, I couldn't test the patch due to lack of access to the L2 > hardware. Actually there was a typo such that driver thought it had > no link at all. I've updated diff(URL is the same) so please try > again. > -- Best regards, Claudiu Vasadi From owner-freebsd-net@FreeBSD.ORG Mon Jul 15 14:57:24 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 70F77A35 for ; Mon, 15 Jul 2013 14:57:24 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm41.bullet.mail.ne1.yahoo.com (nm41.bullet.mail.ne1.yahoo.com [98.138.120.48]) by mx1.freebsd.org (Postfix) with ESMTP id 2419C10A for ; Mon, 15 Jul 2013 14:57:23 +0000 (UTC) Received: from [98.138.90.54] by nm41.bullet.mail.ne1.yahoo.com with NNFMP; 15 Jul 2013 14:54:21 -0000 Received: from [98.138.226.168] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 15 Jul 2013 14:54:21 -0000 Received: from [127.0.0.1] by omp1069.mail.ne1.yahoo.com with NNFMP; 15 Jul 2013 14:54:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 35130.88450.bm@omp1069.mail.ne1.yahoo.com Received: (qmail 60323 invoked by uid 60001); 15 Jul 2013 14:54:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1373900061; bh=h5DHbbHFbPMZHqG5QatmhBYNZJ8bosJFQEhlHU2P/5I=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=RpgGnWVS7xFAW8szfDSSm0vSuwL4HhFu5ijjd0VJvYLQRAr2W5CaUPoHwXrcjXIbLfXUvxrXGGkgst0s22jOo+HTF0XBScOChq6w/+ny2mN1pTmBJIkf9ZCfXcb+17jI8DoUPqpuudOtH/SbC8vquHmSpqvm+KD8PGREdJL0Jis= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=E1CH4xXfwozo8oRRQRQ9bPZAyKSpL75vxpigS/7to1TNO18WbKBxbAnkpMbHRN4hnxRgPHGJwmBAQMFWdxib0qy2MceiuT7rJiHlIo47oJ+bjSCAsJsit5KZajxLmJmkFZ77ik+ffP21nlU3nm45PQRG79QqrhGWzW4mOYIlZ44= ; X-YMail-OSG: _Zh7mP4VM1mF.v4BJAy7n8WBhBHUs8h_4gqwrgEvjhiz_yH f01ro92nhmIMA803BLeMcqc4ZimS.UCpOcazqXYBwm0UegRvdrz8mCcaR1Rq 0TSzl4jvMfipmULLA_sOFiebTkyVxlxdHyaun90_LT6d2LGUQMphaA9UJrJ6 H04ZqIbxhjKx3a23MBDotaIyBz3OVdSEZAVpgBXDwZWFOQjYbUFjcKYC.dse LDmG8Jww2F2GTjHPsqDdmHKY0BtbgbKHUfjvo6NahQfqTk5xyyhzl8BBPHaC vntY4yz_hT4.ElVyrpDDb6oS.yJOQlqnJHxr85jVA1xtIq30w7LAFijL9CBF pMUcjhwDsuhQExQesEoLqCCRnD_s0fzD6rD4gMZg4dxH5e78CCdpoA3hwwbG LyZ36Tnxdk8CBbv2QluGntuJUYgmXQoBxlvsGPOhx4ssxB2pNJ19LoAnyoHR Cb0.grM1QkAJ_pPmrEV9Y8RvLYFDVvcBACuSoHrsGsoUMNWiXoA75nK1YCbr 0EK425yq8a6.Z1DFuVgpmA_w4g0A8oyGv8EC1j42l2WSnkQJ3YQuOJvVM6ad inB_9AjnTOJ9loI_XlZF0Eo5jagEw Received: from [98.203.118.124] by web121603.mail.ne1.yahoo.com via HTTP; Mon, 15 Jul 2013 07:54:20 PDT X-Rocket-MIMEInfo: 002.001, DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KT24gU3VuLCA3LzE0LzEzLCBFdWdlbmUgR3Jvc2JlaW4gPGV1Z2VuQGdyb3NiZWluLm5ldD4gd3JvdGU6DQoNCiBTdWJqZWN0OiBSZTogRnJlZUJTRCByb3V0ZXIgcHJvYmxlbXMNCiBUbzogIkJhcm5leSBDb3Jkb2JhIiA8YmFybmV5X2NvcmRvYmFAeWFob28uY29tPg0KIENjOiAiaXNwIiA8bWxpbmVAdWtyLm5ldD4sIGZyZWVic2QtbmV0QGZyZWVic2Qub3JnDQogRGF0ZTogU3VuZGF5LCBKdWx5IDE0LCAyMDEzLCAxOjE3IFABMAEBAQE- X-Mailer: YahooMailClassic/1000012 YahooMailWebService/0.8.148.557 Message-ID: <1373900060.59867.YahooMailBasic@web121603.mail.ne1.yahoo.com> Date: Mon, 15 Jul 2013 07:54:20 -0700 (PDT) From: Barney Cordoba Subject: Re: FreeBSD router problems To: Eugene Grosbein In-Reply-To: <51E2DD34.3040006@grosbein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org, isp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 14:57:24 -0000 -------------------------------------------- On Sun, 7/14/13, Eugene Grosbein wrote: Subject: Re: FreeBSD router problems To: "Barney Cordoba" Cc: "isp" , freebsd-net@freebsd.org Date: Sunday, July 14, 2013, 1:17 PM On 14.07.2013 23:14, Barney Cordoba wrote: > So why not get a real 10gb/s card? RJ45 10gig is here, > and it works a lot better than LAGG. > > If you want to get more than 1Gb/s on a single connection, > you'd need to use roundrobin, which will alternate packets > without concern for ordering. Purists will argue against it, > but it does work and modern TCP stacks know how to deal > with out of order packets. Except of FreeBSD's packet reassembly is broken for long time. For example, http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/167603 ------------------------------------- NFS has been broken since the beginning of time. NFS has always had problems sending segments > the packet size. There are a lot of ISPs that load balance multiple feeds so OOO packets are a normal occurrence. A stack that doesn't handle out of order tcp packets doesn't work in today's world. BC From owner-freebsd-net@FreeBSD.ORG Mon Jul 15 15:06:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 283BD4D7 for ; Mon, 15 Jul 2013 15:06:34 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm32-vm9.bullet.mail.ne1.yahoo.com (nm32-vm9.bullet.mail.ne1.yahoo.com [98.138.229.57]) by mx1.freebsd.org (Postfix) with ESMTP id CF7A11C9 for ; Mon, 15 Jul 2013 15:06:33 +0000 (UTC) Received: from [98.138.226.176] by nm32.bullet.mail.ne1.yahoo.com with NNFMP; 15 Jul 2013 15:04:35 -0000 Received: from [98.138.89.254] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 15 Jul 2013 15:04:35 -0000 Received: from [127.0.0.1] by omp1046.mail.ne1.yahoo.com with NNFMP; 15 Jul 2013 15:04:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 190542.47244.bm@omp1046.mail.ne1.yahoo.com Received: (qmail 36102 invoked by uid 60001); 15 Jul 2013 15:04:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1373900675; bh=TKwV7v/W1JJID3BaytgSkWObH+N2aCqW5ATBybDTkZs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=JuoBDVT/dyzckZixAjk09BMSmm1+efYJCRgPHVr5yP9R/YHPbYPEPkBY9TOYEyc0G6YEt9oIboSKd71Pp/aijItNcL38/IVd7xnIMBop4c2kJ88sJwfRVe0HZplj1sN2+3qnFn4hvCa0BmZl0zJHGQMj35KqzzHkioSDM7lFUm4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ksT5f1cdLnnveEUQ/3DuGFIi6vynmcJweLVjsfaS2rJUdH85ETSrvnFvjYorlicllFuklhd3XmWFXNDan5aij1iPTcPk5plG3KMeAsQEVy38EzIzyvaW4zBa8QC7qQPdbj9aaeXzvlicyfw1NvlHWaEAyZuZ3uYbFHzOtcEOJXA= ; X-YMail-OSG: JORHrlkVM1kxPeRhGP6iEwn6VLsskBklxr9KkgxIL4KNkuF Q1_n9gUyyLhM70YZwKLrnVBxp0pxZrSejjgvOFzv0rvT1Eq7_Gh0qdVjIMhN VGXTO7R9fx6ruSg9Z9Xe6cJ5qSMQ3QTlsq1FB.M6i4YqsQPUsOYrdYV6U2Uz uE.62HImJByA46uSsVHaYGExNrks.jo3AsRXELQxIWoOkMZ9nybslj5OAnP0 wAI4W6qiZSyf2AjDUxiaQkx4NPv8a5DaKQ4xXHHJHup1Syk1pgWGNWLMA_jN NhUf1gR9Ks4M9nIwJxFBw65awA4r6duhHvCMBotUmY1xroU1ZepKjUga2vmI M_q1hYQfZ6ftFnPkF_Fs.u._MdU4zQjA3Gxq8.Vhu8mwJcIoFaU6IoYkhhru Eyz8wwpbMFv9wH4EnPEbtHhuRqB3VJmGcQ6nkR8oUkZ9EAs2STfzJox5ALJJ RiOEOMhwPTHAj681AAHcGzVY5EBgaGgiOzqOcV5Nno0A8B_uWyz7kNOUKJFW UP_1UQY0blxtynl4cRhXWK6NFQUlijz.x9mWNt0sFMbo3QtL8oKTvOIrLGE_ O3P48hUGiilMKonc3EtNog5rPQSQQ Received: from [98.203.118.124] by web121605.mail.ne1.yahoo.com via HTTP; Mon, 15 Jul 2013 08:04:35 PDT X-Rocket-MIMEInfo: 002.001, DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KT24gU3VuLCA3LzE0LzEzLCBFdWdlbmUgR3Jvc2JlaW4gPGV1Z2VuQGdyb3NiZWluLm5ldD4gd3JvdGU6DQoNCiBTdWJqZWN0OiBSZTogRnJlZUJTRCByb3V0ZXIgcHJvYmxlbXMNCiBUbzogIkJhcm5leSBDb3Jkb2JhIiA8YmFybmV5X2NvcmRvYmFAeWFob28uY29tPg0KIENjOiBmcmVlYnNkLW5ldEBmcmVlYnNkLm9yZywgImlzcCIgPG1saW5lQHVrci5uZXQ.DQogRGF0ZTogU3VuZGF5LCBKdWx5IDE0LCAyMDEzLCAxOjE3IFABMAEBAQE- X-Mailer: YahooMailClassic/1000012 YahooMailWebService/0.8.148.557 Message-ID: <1373900675.35372.YahooMailBasic@web121605.mail.ne1.yahoo.com> Date: Mon, 15 Jul 2013 08:04:35 -0700 (PDT) From: Barney Cordoba Subject: Re: FreeBSD router problems To: Eugene Grosbein In-Reply-To: <51E2DD34.3040006@grosbein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org, isp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 15:06:34 -0000 -------------------------------------------- On Sun, 7/14/13, Eugene Grosbein wrote: Subject: Re: FreeBSD router problems To: "Barney Cordoba" Cc: freebsd-net@freebsd.org, "isp" Date: Sunday, July 14, 2013, 1:17 PM On 14.07.2013 23:14, Barney Cordoba wrote: > So why not get a real 10gb/s card? RJ45 10gig is here, > and it works a lot better than LAGG. > > If you want to get more than 1Gb/s on a single connection, > you'd need to use roundrobin, which will alternate packets > without concern for ordering. Purists will argue against it, > but it does work and modern TCP stacks know how to deal > with out of order packets. Except of FreeBSD's packet reassembly is broken for long time. For example, http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/167603 _______________________________________________ Also, IP fragmentation and TCP segments are not the same thing. TCP segments regularly will come in out of order, NFS is too stupid to do things correctly; IP fragmentation should not be done unless necessary to accommodate a smaller mtu. BC From owner-freebsd-net@FreeBSD.ORG Mon Jul 15 19:33:13 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F26D573 for ; Mon, 15 Jul 2013 19:33:13 +0000 (UTC) (envelope-from trafdev@mail.ru) Received: from fallback5.mail.ru (fallback5.mail.ru [94.100.176.59]) by mx1.freebsd.org (Postfix) with ESMTP id AAAAA314 for ; Mon, 15 Jul 2013 19:33:13 +0000 (UTC) Received: from smtp34.i.mail.ru (smtp34.i.mail.ru [94.100.177.94]) by fallback5.mail.ru (mPOP.Fallback_MX) with ESMTP id 2856BED9B983 for ; Mon, 15 Jul 2013 23:32:10 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=hf9Io5kQsfDTxEbC/yMPEwPdrqlkZ5m4Cp58epvFt00=; b=PjMo8CplpUhxP/FjnUohfqz/AI/EEJvVngrU0unQT5lC8AAnmcs6OG7pd4+68s6jWUsOxzqbAeIag1bgJKOKpO20U5JeRJVJeirqoUI/NBB9d1vF+LwusMBT7+4+5lfd8T9zyYZgdk3Zt1a3UlIri+Rg90ADD1iGOyZnlDax/aI=; Received: from [50.156.108.197] (port=39544 helo=[192.168.1.116]) by smtp34.i.mail.ru with esmtpa (envelope-from ) id 1UyoV8-00015T-Nx; Mon, 15 Jul 2013 23:32:03 +0400 Message-ID: <51E44E2F.8060700@mail.ru> Date: Mon, 15 Jul 2013 12:31:59 -0700 From: trafdev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: Sepherosa Ziehau Subject: Re: SO_REUSEPORT: strange kernel balancer behaviour References: <51E0E2AF.7090404@mail.ru> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 19:33:14 -0000 Thanks for reply. This approach produces lot of "resource temporary unavailable" (eagain) on accept-ing connections in N-1 processes. Is this possible to avoid this by e.g. tweaking kqueue? On Sun Jul 14 19:37:59 2013, Sepherosa Ziehau wrote: > On Sat, Jul 13, 2013 at 1:16 PM, trafdev wrote: >> Hello. >> >> Could someone help with following problem of SO_REUSEPORT. > > The most portable "load balance" between processes listening on the > same TCP addr/port probably is: > > s=socket(); > bind(s); > listen(s); > /* various socketopt and fcntl as you needed */ > pid=fork(); > if (pid==0) { > server_loop(s); > exit(1); > } > server_loop(s); > exit(1); > > Even in Linux or DragonFly SO_REUSEPORT "load balance" between > processes listening on the same TCP addr/port was introduced recently, > so you probably won't want to rely on it. > > Best Regards, > sephe > From owner-freebsd-net@FreeBSD.ORG Mon Jul 15 19:53:56 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E8FA6DBC for ; Mon, 15 Jul 2013 19:53:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 8507477E for ; Mon, 15 Jul 2013 19:53:56 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id ey16so3344720wid.1 for ; Mon, 15 Jul 2013 12:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FFi8r4QIspy4JkFfQ0Yn4KG7s4gPU0ncj+DsuZMfyy4=; b=PLP2/LBkF5wV43xsCbRK6Rju/uCGqScliNIyo9N4aJU2Zqsn+3UvZvUQzbjUNsGZwW VM/fKrDdf7ipoD9ronSXa41jld1uDXwYsRlvVjlaTeUrPNZ4JAUfa1ynS4iwoupW2zG+ Xs/D/nHUCZaZxee+WvSKeLKO9jBcTPGNdZOn1udt3Dn+7suISIVDZipF+sRJq7NUbC82 NzXObr+tncg9p36103PTofn6nhIU8wvkhx6K17Wpu9ZBJauFEOwxek5if8AvrRwdvFYy PTe+naoUK7ZWC6dxDD4/txxumQs0XrK5vVIY4gsQPVVcfHH/ptMQXPbctWrK5DdCgYPs 9/eQ== MIME-Version: 1.0 X-Received: by 10.194.63.229 with SMTP id j5mr32047253wjs.79.1373918035486; Mon, 15 Jul 2013 12:53:55 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Mon, 15 Jul 2013 12:53:55 -0700 (PDT) In-Reply-To: <51E44E2F.8060700@mail.ru> References: <51E0E2AF.7090404@mail.ru> <51E44E2F.8060700@mail.ru> Date: Mon, 15 Jul 2013 12:53:55 -0700 X-Google-Sender-Auth: QwNw1wSwdin8TxjNz94yd2yTF4E Message-ID: Subject: Re: SO_REUSEPORT: strange kernel balancer behaviour From: Adrian Chadd To: trafdev Content-Type: text/plain; charset=ISO-8859-1 Cc: Sepherosa Ziehau , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 19:53:57 -0000 i've noticed this when doing this stuff in a threaded program with each thread listening on the same port. All threads wake up on each accepted connection, one thread wins and the other threads get EAGAIN. -adrian On 15 July 2013 12:31, trafdev wrote: > Thanks for reply. > > This approach produces lot of "resource temporary unavailable" (eagain) on > accept-ing connections in N-1 processes. > Is this possible to avoid this by e.g. tweaking kqueue? > > > On Sun Jul 14 19:37:59 2013, Sepherosa Ziehau wrote: >> >> On Sat, Jul 13, 2013 at 1:16 PM, trafdev wrote: >>> >>> Hello. >>> >>> Could someone help with following problem of SO_REUSEPORT. >> >> >> The most portable "load balance" between processes listening on the >> same TCP addr/port probably is: >> >> s=socket(); >> bind(s); >> listen(s); >> /* various socketopt and fcntl as you needed */ >> pid=fork(); >> if (pid==0) { >> server_loop(s); >> exit(1); >> } >> server_loop(s); >> exit(1); >> >> Even in Linux or DragonFly SO_REUSEPORT "load balance" between >> processes listening on the same TCP addr/port was introduced recently, >> so you probably won't want to rely on it. >> >> Best Regards, >> sephe >> > _______________________________________________ > 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 15 20:06:29 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 09B522EF; Mon, 15 Jul 2013 20:06:29 +0000 (UTC) (envelope-from trafdev@mail.ru) Received: from fallback5.mail.ru (fallback5.mail.ru [94.100.176.59]) by mx1.freebsd.org (Postfix) with ESMTP id 811AE85F; Mon, 15 Jul 2013 20:06:28 +0000 (UTC) Received: from smtp3.mail.ru (smtp3.mail.ru [94.100.176.131]) by fallback5.mail.ru (mPOP.Fallback_MX) with ESMTP id B2350ED9F3CF; Tue, 16 Jul 2013 00:04:47 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=DKLv2iT3gm7vawe9j4Ixd+HwfaxL8QWdUCULi4TBstA=; b=Ja7BQQqbNU9aQ8GAtozfqpVmrmQyTMWZvKry9PpHGRhsfyW4etSGMQ+oXaCeiogZbZaHgUJWxSvPul+59Jg+HaK37764K7pz6g8eWe0ePvJh1ZiPxJWLcb6bA64IlvOy6fx1C6fbbHxST0MHe1t40w1YqU/PAZ8PuB45Nry4VBc=; Received: from [50.156.108.197] (port=62579 helo=[192.168.1.116]) by smtp3.mail.ru with esmtpa (envelope-from ) id 1Uyp0i-00037q-3y; Tue, 16 Jul 2013 00:04:40 +0400 Message-ID: <51E455D5.2090403@mail.ru> Date: Mon, 15 Jul 2013 13:04:37 -0700 From: trafdev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: SO_REUSEPORT: strange kernel balancer behaviour References: <51E0E2AF.7090404@mail.ru> <51E44E2F.8060700@mail.ru> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Cc: Sepherosa Ziehau , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 20:06:29 -0000 Yep I think it's wasting of resources, poll manager should somehow be configured to update only one process/thread. Anyone know how to do that? Thanks. On Mon Jul 15 12:53:55 2013, Adrian Chadd wrote: > i've noticed this when doing this stuff in a threaded program with > each thread listening on the same port. > > All threads wake up on each accepted connection, one thread wins and > the other threads get EAGAIN. > > > > -adrian > > On 15 July 2013 12:31, trafdev wrote: >> Thanks for reply. >> >> This approach produces lot of "resource temporary unavailable" (eagain) on >> accept-ing connections in N-1 processes. >> Is this possible to avoid this by e.g. tweaking kqueue? >> >> >> On Sun Jul 14 19:37:59 2013, Sepherosa Ziehau wrote: >>> >>> On Sat, Jul 13, 2013 at 1:16 PM, trafdev wrote: >>>> >>>> Hello. >>>> >>>> Could someone help with following problem of SO_REUSEPORT. >>> >>> >>> The most portable "load balance" between processes listening on the >>> same TCP addr/port probably is: >>> >>> s=socket(); >>> bind(s); >>> listen(s); >>> /* various socketopt and fcntl as you needed */ >>> pid=fork(); >>> if (pid==0) { >>> server_loop(s); >>> exit(1); >>> } >>> server_loop(s); >>> exit(1); >>> >>> Even in Linux or DragonFly SO_REUSEPORT "load balance" between >>> processes listening on the same TCP addr/port was introduced recently, >>> so you probably won't want to rely on it. >>> >>> Best Regards, >>> sephe >>> >> _______________________________________________ >> 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 15 20:31:36 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 76B92851 for ; Mon, 15 Jul 2013 20:31:36 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by mx1.freebsd.org (Postfix) with ESMTP id 124B9959 for ; Mon, 15 Jul 2013 20:31:35 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id hj3so3341583wib.0 for ; Mon, 15 Jul 2013 13:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=PVBtUMzkgfUhebV5cyDKGw9HJuulErVwwOZWe1ojy+M=; b=0et63LPpwm6TmM7Y7lH60sbDJk7dFpAaQebvg2S+NXyHHv2TybLbAzjy077rcdGbLp D7LNImrc/uDpGJs1ILstFGRkkzpRSJT4k1q4wTO0vdL5cVIkm/D6+IBouUSshL0SLc+Y GbwofW3UtUQZIzQXi4uXIUxl1EST38zL/0FJ/VtRCc2Xiz+GqT8UfJ//XSd4lDVJnNaD F2k7wUO1i/vF797AhcygQ17R+2HIr/xL3LSSJIOq1Sai1T7ac6gqGxgcRJvPOdrX5KfQ wyMlw1BOh/vbgvhOqDH4fOstOukSPuJnzaDxkaApG7OXa9+E7h/4kMru5ahQrIMfdfyp wv2Q== MIME-Version: 1.0 X-Received: by 10.180.185.148 with SMTP id fc20mr10246721wic.0.1373920295252; Mon, 15 Jul 2013 13:31:35 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Mon, 15 Jul 2013 13:31:35 -0700 (PDT) In-Reply-To: <51E455D5.2090403@mail.ru> References: <51E0E2AF.7090404@mail.ru> <51E44E2F.8060700@mail.ru> <51E455D5.2090403@mail.ru> Date: Mon, 15 Jul 2013 13:31:35 -0700 X-Google-Sender-Auth: R1ZMYLnnYBDrJLNlAiPcjGYD0m4 Message-ID: Subject: Re: SO_REUSEPORT: strange kernel balancer behaviour From: Adrian Chadd To: trafdev Content-Type: text/plain; charset=ISO-8859-1 Cc: Sepherosa Ziehau , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jul 2013 20:31:36 -0000 On 15 July 2013 13:04, trafdev wrote: > Yep I think it's wasting of resources, poll manager should somehow be > configured to update only one process/thread. > Anyone know how to do that? > Thanks. Well, the problem here is deciding which thread to throw the request at. If the threads are equally busy, you're ok. If the threads aren't equally busy, then just doing a round robin or hash may end up keeping one thread more busy than others, skewing the workload. I'm also interested in the whole CPU pinning of sockets to line it all up with multi-queue network cards and such. Hence why I'm starting down this path. -adrian From owner-freebsd-net@FreeBSD.ORG Tue Jul 16 05:10:47 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7810625E for ; Tue, 16 Jul 2013 05:10:47 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id C1E74E5A for ; Tue, 16 Jul 2013 05:10:46 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.7/8.14.7) with ESMTP id r6G5AfH6023867; Tue, 16 Jul 2013 12:10:42 +0700 (NOVT) (envelope-from eugen@grosbein.net) Message-ID: <51E4D5CC.9030601@grosbein.net> Date: Tue, 16 Jul 2013 12:10:36 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: Barney Cordoba Subject: Re: FreeBSD router problems References: <1373900675.35372.YahooMailBasic@web121605.mail.ne1.yahoo.com> In-Reply-To: <1373900675.35372.YahooMailBasic@web121605.mail.ne1.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Jul 2013 05:10:47 -0000 On 15.07.2013 22:04, Barney Cordoba wrote: > Also, IP fragmentation and TCP segments are not the same thing. TCP > segments regularly will come in out of order, NFS is too stupid to do > things correctly; IP fragmentation should not be done unless necessary > to accommodate a smaller mtu. The PR is about NFS over UDP, not TCP. From owner-freebsd-net@FreeBSD.ORG Tue Jul 16 11:32:54 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4451D7D; Tue, 16 Jul 2013 11:32:54 +0000 (UTC) (envelope-from logan@elandsys.com) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id F0A45F2C; Tue, 16 Jul 2013 11:32:53 +0000 (UTC) Received: from mx.elandsys.com (IDENT:logan@localhost [127.0.0.1]) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r6GBWnRr019830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 04:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1373974371; bh=3vVTiCkSw8R7ULCp7d7myCauAPH6KemGqP6QjWDUi2M=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=CGxrzx6y3d3tiNijL41MVhj+7A52tEIlosnKCTux15pNjQE5uut19Zub02RWUOBJE FXyrX9yFtCAnOrMrxqGfTjLwa4Bl0m2fmbVU/WDxy0/cOsJT5fwiLAL9bTSYk4jDS6 DqSP59GHvJEpH+jvHEcysP2Ly+i9NydXldD/f6CY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1373974371; i=@elandsys.com; bh=3vVTiCkSw8R7ULCp7d7myCauAPH6KemGqP6QjWDUi2M=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=JKo89K5oBT0eOmNWSU+kxP7QmpS/zZ7p9Ns1RrYqQvQEzrsvIyQPz2nNh+fBGgXV+ Sr8ZxaQWDhfT4WuprSAAuJepqSkz5e+yA2Shr5Au1Bch9wXHfsB8DEutXRG/sjx+rm u2a8hBy76L8OPKNIAEmBjSHoOjVwkfilskq3Gjzo= Received: (from logan@localhost) by mx.elandsys.com (8.14.5/8.14.5/Submit) id r6GBWn7t023718; Tue, 16 Jul 2013 04:32:49 -0700 (PDT) X-Authentication-Warning: mx.elandsys.com: logan set sender to logan@elandsys.com using -f Date: Tue, 16 Jul 2013 04:32:49 -0700 From: Loganaden Velvindron To: Andre Oppermann Subject: Re: Improved SYN Cookies: Looking for testers Message-ID: <20130716113249.GA6638@mx.elandsys.com> References: <51DA68B8.6070201@freebsd.org> <20130710151821.5a8cf38a@fabiankeil.de> <51DE6E86.6080707@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51DE6E86.6080707@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Jul 2013 11:32:54 -0000 On Thu, Jul 11, 2013 at 10:36:22AM +0200, Andre Oppermann wrote: > On 10.07.2013 15:18, Fabian Keil wrote: > >Andre Oppermann wrote: > > > >>We have a SYN cookie implementation for quite some time now but it > >>has some limitations with current realities for window scaling and > >>SACK encoding the in the few available bits. > >> > >>This patch updates and improves SYN cookies mainly by: > >> > >> a) encoding of MSS, WSCALE (window scaling) and SACK into the ISN > >> (initial sequence number) without the use of timestamp bits. > >> > >> b) switching to the very fast and cryptographically strong SipHash-2-4 > >> hash MAC algorithm to protect the SYN cookie against forgery. > >> > >>The patch had been reviewed by dwmalone (cookies) and cperciva (siphash). > >> > >>Please find it here for testing: > >> > >> http://people.freebsd.org/~andre/syncookie-20130708.diff > > > >I've been using the patch for a couple of days and didn't notice any > >issues so far. Privoxy's regression tests continue to work as expected > >as well. > > Thanks for testing and reporting back. We are currently downloading FreeBSD -current snapshot for testing. Unfortunately, we've been hit by a number of SYN flood attacks recently, and your patch looks very promising. Would there be interest in reviewing backported patched for 9.x release ? > > Could you test with net.inet.tcp.log_debug and net.inet.tcp.syncookies_only=1 > as well to bypass the syn cache entirely? > > It will give a bit of debug log output which is it telling you mostly about > rounding to the next nearest index value. You can send the output privately > to me to spot unexpected outliers, if any. > > >BTW, I think kern/173309 could be closed. > > OK. > > -- > Andre > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Jul 16 12:57:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 54F71703 for ; Tue, 16 Jul 2013 12:57:34 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm1-vm4.bullet.mail.ne1.yahoo.com (nm1-vm4.bullet.mail.ne1.yahoo.com [98.138.91.161]) by mx1.freebsd.org (Postfix) with ESMTP id 08CB03F4 for ; Tue, 16 Jul 2013 12:57:33 +0000 (UTC) Received: from [98.138.90.48] by nm1.bullet.mail.ne1.yahoo.com with NNFMP; 16 Jul 2013 12:54:29 -0000 Received: from [98.138.101.169] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 16 Jul 2013 12:54:29 -0000 Received: from [127.0.0.1] by omp1080.mail.ne1.yahoo.com with NNFMP; 16 Jul 2013 12:54:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 12828.88058.bm@omp1080.mail.ne1.yahoo.com Received: (qmail 60674 invoked by uid 60001); 16 Jul 2013 12:54:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1373979268; bh=CLKZ4PSdOQ/bC99HHPAhhO1lgShuiIwrqDe7dATDaHw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=0WIgAcQoW3KtczszygLLAsCM6qJhF1lvO0mKDpEiNvc/Td3MiHw//B64LW6MPugx9cOJsiTcGIkvi7o3EHiZhRX9cg8YaTc7xQzZXfpEMse5WJJwfN5+5aW3XID08/qiy2Ff/2tC+xY0vV8ZoS1bU+VzDFlL1W10iYWCypyIQ00= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=POVoFzqlsm7HORYY4S3VsYHKLa/QBtqGmWRqxUFdFIRk+Ulwd0x+Jk0/IgrH4GROewNmYyEJ8yA17FeBcwVj6MQd1wzQyMQpzVK+yoWh0az1rr9F5CRHA+TgAVjXrEU08LNUJjd3s1jFg8hIYl/KTa205+whY73JQQjo/vH2vvo= ; X-YMail-OSG: AKspF7oVM1kiiWKvkbMe3l43VD7422Gslg5kHVgnMBs3SVJ mG6ls1cQlrqeXTOZlxqC7PXIHdVJfhrPhTHXoWt9FVIOyjgMkzW3EVJke9NW kiE2unuT4p5fAlvmLE17qxgevcowb2HfOFWLm_bYHTRSZQKULoBPpVSh0KSz 0inJGjGsfvqkjTK1COO84BCgfhB4TxxmvRk9kehxe9xwH_QuPo4aKDkpuuEK PFcoMlDnSHCeocp2zNZ6otmATbuFG6P6pHrMQ8cGyzUg2aiVDS.lMg2XNkfo W6ZO7QqqPCO8BA1CS7ptFc5ImV8_0OcUC1goMmJFdcbCRAqqjKIuIaAk_1oR Uku.MPTvR8RwZ2zDUCEMCUObdRAzhIQo_xPjlG9RLG6OmV8VzeCWSgSci9Po vrfktnkT6zGHm54moLd0BJtTLNxdD4TH4_d3t6R93bg1bDqCNVc1lmzn3ysE f84NFjaDf2DKVBYdDdQzRyoocL4Eb6bxyKbXGbz2P4ZpX3vCWSi_U4ggJY8T GRbgtsngejTwVBsqF3HF18ywMUmMeIVy4xpVprAIXA_doZn8Ulf0JxBWwz9j GNvUwESiss7LCY_2w Received: from [98.203.118.124] by web121605.mail.ne1.yahoo.com via HTTP; Tue, 16 Jul 2013 05:54:28 PDT X-Rocket-MIMEInfo: 002.001, DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KT24gVHVlLCA3LzE2LzEzLCBFdWdlbmUgR3Jvc2JlaW4gPGV1Z2VuQGdyb3NiZWluLm5ldD4gd3JvdGU6DQoNCiBTdWJqZWN0OiBSZTogRnJlZUJTRCByb3V0ZXIgcHJvYmxlbXMNCiBUbzogIkJhcm5leSBDb3Jkb2JhIiA8YmFybmV5X2NvcmRvYmFAeWFob28uY29tPg0KIENjOiBmcmVlYnNkLW5ldEBmcmVlYnNkLm9yZw0KIERhdGU6IFR1ZXNkYXksIEp1bHkgMTYsIDIwMTMsIDE6MTAgQU0NCiANCiBPbiAxNS4wNy4yMDEzIDIBMAEBAQE- X-Mailer: YahooMailClassic/1000012 YahooMailWebService/0.8.148.557 Message-ID: <1373979268.60540.YahooMailBasic@web121605.mail.ne1.yahoo.com> Date: Tue, 16 Jul 2013 05:54:28 -0700 (PDT) From: Barney Cordoba Subject: Re: FreeBSD router problems To: Eugene Grosbein In-Reply-To: <51E4D5CC.9030601@grosbein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Jul 2013 12:57:34 -0000 -------------------------------------------- On Tue, 7/16/13, Eugene Grosbein wrote: Subject: Re: FreeBSD router problems To: "Barney Cordoba" Cc: freebsd-net@freebsd.org Date: Tuesday, July 16, 2013, 1:10 AM On 15.07.2013 22:04, Barney Cordoba wrote: > Also, IP fragmentation and TCP segments are not the same thing. TCP > segments regularly will come in out of order, NFS is too stupid to do > things correctly; IP fragmentation should not be done unless necessary > to accommodate a smaller mtu. The PR is about NFS over UDP, not TCP. ------------------ Ok, so is there evidence that it's UDP and not an IP fragmenting problem? Out of Order UDP is the same issue; its common for packets to traverse different paths through the internet in the same connection, so OOO packets are normal. IP fragmentation is rare, except for NFS. A lot of ISPs will block fragmentation because it's difficult to shape or filter fragments; they're often used to defeat simple firewalls and filters. BC _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Jul 16 13:58:56 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8BEAC27A for ; Tue, 16 Jul 2013 13:58:56 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 036A4892 for ; Tue, 16 Jul 2013 13:58:55 +0000 (UTC) Received: (qmail 85230 invoked from network); 16 Jul 2013 14:48:29 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 16 Jul 2013 14:48:29 -0000 Message-ID: <51E55195.6000205@freebsd.org> Date: Tue, 16 Jul 2013 15:58:45 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Loganaden Velvindron Subject: Re: Improved SYN Cookies: Looking for testers References: <51DA68B8.6070201@freebsd.org> <20130710151821.5a8cf38a@fabiankeil.de> <51DE6E86.6080707@freebsd.org> <20130716113249.GA6638@mx.elandsys.com> In-Reply-To: <20130716113249.GA6638@mx.elandsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Jul 2013 13:58:56 -0000 On 16.07.2013 13:32, Loganaden Velvindron wrote: > On Thu, Jul 11, 2013 at 10:36:22AM +0200, Andre Oppermann wrote: >> On 10.07.2013 15:18, Fabian Keil wrote: >>> Andre Oppermann wrote: >>> >>>> We have a SYN cookie implementation for quite some time now but it >>>> has some limitations with current realities for window scaling and >>>> SACK encoding the in the few available bits. >>>> >>>> This patch updates and improves SYN cookies mainly by: >>>> >>>> a) encoding of MSS, WSCALE (window scaling) and SACK into the ISN >>>> (initial sequence number) without the use of timestamp bits. >>>> >>>> b) switching to the very fast and cryptographically strong SipHash-2-4 >>>> hash MAC algorithm to protect the SYN cookie against forgery. >>>> >>>> The patch had been reviewed by dwmalone (cookies) and cperciva (siphash). >>>> >>>> Please find it here for testing: >>>> >>>> http://people.freebsd.org/~andre/syncookie-20130708.diff >>> >>> I've been using the patch for a couple of days and didn't notice any >>> issues so far. Privoxy's regression tests continue to work as expected >>> as well. >> >> Thanks for testing and reporting back. > > We are currently downloading FreeBSD -current snapshot for testing. > > Unfortunately, we've been hit by a number of SYN flood attacks recently, > and your patch looks very promising. It should help a lot. > Would there be interest in reviewing backported patched for 9.x release ? A backport should be straight forward. I currently can't commit it because of feature freeze for the upcoming 9.2 release cycle. Once the 9.2 branch has been created I'll do the MFC to 9-stable. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Jul 16 14:58:45 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 07FA47E4; Tue, 16 Jul 2013 14:58:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id D962BBEC; Tue, 16 Jul 2013 14:58:44 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EA7ECB91C; Tue, 16 Jul 2013 10:58:43 -0400 (EDT) From: John Baldwin To: "Mr. Clif" Subject: Re: misc/179033: [dc] dc ethernet driver seems to have issues with some multiport card and mother board combinations Date: Tue, 16 Jul 2013 10:58:33 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201305300113.r4U1DRGp089692@freefall.freebsd.org> <201306241738.47350.jhb@freebsd.org> <51CA6FF9.60805@eugeneweb.com> In-Reply-To: <51CA6FF9.60805@eugeneweb.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201307161058.33341.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 16 Jul 2013 10:58:44 -0400 (EDT) Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, yongari@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Jul 2013 14:58:45 -0000 On Wednesday, June 26, 2013 12:37:13 am Mr. Clif wrote: > Hi John, > > Thanks for working on this. I'm very interested in getting this fixed > for everyone that uses the Affected Atom boards and other small format > boards that work well in small custom routers. > > However right now I have a big network upgrade I'm working on and don't > have time to get to it until late July, I'm hoping. So please forgive me > for the long delay. > > Thanks for your help, > Clif I've tested your specific case more by hacking the PCI bus driver to assign a bogus range to my NIC on my netbook and verifying it rejected the request and allocated a new range. I did have to fix a bug though, so once you get a chance to test, please test http://www.freebsd.org/~jhb/patches/pci_isa_enable2.patch instead. I will go ahead and commit a slightly cleaned up version (with less debugging) today, but the patch above will output enough debugging to verify it is working without requiring a verbose boot. > John Baldwin wrote: > > On Monday, June 10, 2013 3:13:11 pm Mr. Clif wrote: > >> Hi John and Pyun, > >> > >> Ok got the new kernel installed and tested. Yes it works! :-) Maybe that > >> will also fix a simular problem with the sun cards (cas[03]), except I > >> don't see a define like that in if_cas.c. Suggestions? > > So I have a possible "real" fix for this. However, I do not have any hardware > > I can find that has a PCI-PCI bridge with the ISA-enable bit set. I know it > > compiles and boots fine on other systems. Can you please try this and capture > > the dmesg output? It would also be good to capture devinfo -u output before > > and after. > > > > http://www.freebsd.org/~jhb/patches/pci_isa_enable.patch > > > > -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jul 16 15:33:38 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EB50CE56; Tue, 16 Jul 2013 15:33:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id CA30EE93; Tue, 16 Jul 2013 15:33:38 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 339FDB978; Tue, 16 Jul 2013 11:33:38 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org, "sbruno@freebsd.org" Subject: Re: bind error when using SO_REUSEPORT(implies SO_REUSEADDR) Date: Tue, 16 Jul 2013 11:12:46 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <1331855948.3317.17.camel@powernoodle-l7.corp.yahoo.com> <1331856466.3317.18.camel@powernoodle-l7.corp.yahoo.com> In-Reply-To: <1331856466.3317.18.camel@powernoodle-l7.corp.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201307161112.46116.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 16 Jul 2013 11:33:38 -0400 (EDT) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Jul 2013 15:33:39 -0000 On Thursday, March 15, 2012 8:07:46 pm Sean Bruno wrote: > On Thu, 2012-03-15 at 16:59 -0700, Sean Bruno wrote: > > Hey, I just found a bind bug ticket in my queue about bind. I noted > > that on stable/6 stable/7 stable/9 & head the referenced code "fails". > > > > It seems that this is a problem, but I have no idea if its a real > > problem or not. Our devs think it is. Anyway, here is a code snippet > > to show the failure in bind. On linux/solaris this does not fail. > > > > http://people.freebsd.org/~sbruno/bind_test.c > > > > simple compile with gcc -o test test.c and run as normal user. > > > > Sean > > > > this is bind() not bind ... :-) Did the recent commit to HEAD fix this btw? -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jul 16 21:35:50 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BABA6CD1; Tue, 16 Jul 2013 21:35:50 +0000 (UTC) (envelope-from claudiu.vasadi@gmail.com) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id 861992BD; Tue, 16 Jul 2013 21:35:50 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id s9so2680588iec.41 for ; Tue, 16 Jul 2013 14:35:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zYHG7FM/s9TrvtPv5awS47C71fEijV7Dns1cX6j+GvQ=; b=dbE9Roe3EttHEJdpiMcttY1sywzzc+mZPGQ1SP1txcua8uMsUyIVqitzuPUdMjpA8P /62vQgcE2mbIZw/1Im6KAy42MXAHtDJd1z9R3RFTm+W+DNtnr8oG/prmbAZs0GaYaPIl 4ZGGo+E8zWTH6KpX97tAJ7k8vUioxThKZajKAmkzHah9sRRTRFae1/zIBfthqZH1PyuU 7FGDzHSsKu2/zLC8i6i9/8MwPC0mMPaQYqISU8EJajSDi1y7Xsbax/yXtsUMQLoSVVJL CThsC4mwljugwQJdfJRNOV+u02c3Kp27wUZP911EJ/8adcU9DYu8Mze9ThirzpowBlle e8ZA== MIME-Version: 1.0 X-Received: by 10.43.84.131 with SMTP id ak3mr3034548icc.84.1374010550158; Tue, 16 Jul 2013 14:35:50 -0700 (PDT) Received: by 10.64.56.67 with HTTP; Tue, 16 Jul 2013 14:35:50 -0700 (PDT) In-Reply-To: References: <201307091122.r69BM9Ev053001@freefall.freebsd.org> <20130715004358.GA2959@michelle.cdnetworks.com> Date: Tue, 16 Jul 2013 23:35:50 +0200 Message-ID: Subject: Re: kern/180382: [ae] kernel: ae0: watchdog timeout - resetting. From: claudiu vasadi To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org, yongari@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Jul 2013 21:35:50 -0000 Hi again, UPDATE: all is well. 24h have long passed and the server is running fine with the patch. Will it be merged to 9-STABLE? On Mon, Jul 15, 2013 at 3:06 PM, claudiu vasadi wrote: > Hi, > > Quick update: works now. > > Will let you know if it continues like this or if we hit another problem. > > Huge thanks for the patch. > > > On Mon, Jul 15, 2013 at 2:43 AM, Yonghyeon PYUN wrote: > >> On Sun, Jul 14, 2013 at 04:20:30PM +0200, claudiu vasadi wrote: >> > Hi, >> > >> > The patch applied without any problems and the "Size mismatch" messages >> > are gone now. However, we cannot get an IP via "dhclient" and we also >> > don't have any network connectivity if we set a manual IP. The only >> > messages we see now (with the manual IP) is "no buffer space available". >> > I checked the Ip, netmask, gateway and mbufs but they all seem to be ok. >> > "ifconfg ae0 down && ifconfig ae0 up" does not fix the problem. We also >> > tried a reboot but again, it did not fix the problem. We have no ping or >> > anything. >> > >> > No other error messages were observed. >> > >> > PS: Sorry for the late reply but the machine is on a remote site. >> > PS2: I can arrange a ssh account if this would help you. >> > >> >> Sorry, I couldn't test the patch due to lack of access to the L2 >> hardware. Actually there was a typo such that driver thought it had >> no link at all. I've updated diff(URL is the same) so please try >> again. >> > > > > -- > Best regards, > Claudiu Vasadi > -- Best regards, Claudiu Vasadi From owner-freebsd-net@FreeBSD.ORG Wed Jul 17 02:28:12 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 21F14333; Wed, 17 Jul 2013 02:28:12 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by mx1.freebsd.org (Postfix) with ESMTP id EB288D56; Wed, 17 Jul 2013 02:28:11 +0000 (UTC) Received: by mail-pb0-f45.google.com with SMTP id mc8so1353303pbc.32 for ; Tue, 16 Jul 2013 19:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=pBm+D6IbJeFvA23Lat52zNVcG+l9aW5mXnFYv4oqgEk=; b=JQI+aP8KG4ZGaVpMRL592eVAIfyard3si+o87mF9Yn0KeBWFrgY68Mx76PTj95CSbC 60ih2BsfIPp6dd0/pdO8YvkI1InD6WwYGEiyvGlM66GPbX+3uR+jddfyKEF0nBE6KzGl BNTKnjyV/v4qvnYtjEY40THadM1tjxanPOQwQLh8qF7Up8gifkfVKNZkg9B94jfE9RZY pwOvdvRfzOG1mKDbG1NHJhWc5X0sTn1b9y13sGA5NsecniQ1o7eCTPYY0lpfl/gCB7/C Ezc+cnqbTKoxexC37q1KioMqo43kjm+KodaROaHR19al0J9ke3w3HTOmo43INNCguoX8 Z+kA== X-Received: by 10.68.17.169 with SMTP id p9mr4487095pbd.17.1374028091588; Tue, 16 Jul 2013 19:28:11 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id iq6sm4866068pbc.1.2013.07.16.19.28.08 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Jul 2013 19:28:10 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 17 Jul 2013 11:28:04 +0900 From: Yonghyeon PYUN Date: Wed, 17 Jul 2013 11:28:04 +0900 To: claudiu vasadi Subject: Re: kern/180382: [ae] kernel: ae0: watchdog timeout - resetting. Message-ID: <20130717022804.GA2734@michelle.cdnetworks.com> References: <201307091122.r69BM9Ev053001@freefall.freebsd.org> <20130715004358.GA2959@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, yongari@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 02:28:12 -0000 On Tue, Jul 16, 2013 at 11:35:50PM +0200, claudiu vasadi wrote: > Hi again, > > UPDATE: all is well. 24h have long passed and the server is running fine > with the patch. > Thanks a lot for testing. Fixed in r253404. > Will it be merged to 9-STABLE? > Not sure but I'll request re approval after settlement. > > On Mon, Jul 15, 2013 at 3:06 PM, claudiu vasadi wrote: > > > Hi, > > > > Quick update: works now. > > > > Will let you know if it continues like this or if we hit another problem. > > > > Huge thanks for the patch. > > > > > > On Mon, Jul 15, 2013 at 2:43 AM, Yonghyeon PYUN wrote: > > > >> On Sun, Jul 14, 2013 at 04:20:30PM +0200, claudiu vasadi wrote: > >> > Hi, > >> > > >> > The patch applied without any problems and the "Size mismatch" messages > >> > are gone now. However, we cannot get an IP via "dhclient" and we also > >> > don't have any network connectivity if we set a manual IP. The only > >> > messages we see now (with the manual IP) is "no buffer space available". > >> > I checked the Ip, netmask, gateway and mbufs but they all seem to be ok. > >> > "ifconfg ae0 down && ifconfig ae0 up" does not fix the problem. We also > >> > tried a reboot but again, it did not fix the problem. We have no ping or > >> > anything. > >> > > >> > No other error messages were observed. > >> > > >> > PS: Sorry for the late reply but the machine is on a remote site. > >> > PS2: I can arrange a ssh account if this would help you. > >> > > >> > >> Sorry, I couldn't test the patch due to lack of access to the L2 > >> hardware. Actually there was a typo such that driver thought it had > >> no link at all. I've updated diff(URL is the same) so please try > >> again. > >> > > > > > > > > -- > > Best regards, > > Claudiu Vasadi > > > > > > -- > Best regards, > Claudiu Vasadi From owner-freebsd-net@FreeBSD.ORG Wed Jul 17 09:57:01 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 272F3BB1 for ; Wed, 17 Jul 2013 09:57:01 +0000 (UTC) (envelope-from diizzyy@gmail.com) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by mx1.freebsd.org (Postfix) with ESMTP id E64BF1CD for ; Wed, 17 Jul 2013 09:57:00 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id e10so955331qcy.41 for ; Wed, 17 Jul 2013 02:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=TwL7nsCunJMJvr/hUXCnoDlAtvikKdrtn3tNQlNOia0=; b=dIA7wzMDrHlyHvnestCoKIwnQrJ8mKdXVG1DCHrr4HT+CRlspAz6HhzHyeH03qKvT2 XORfnJlKTeSSz1AKZThUmn9Vcd3H5RZaaGQVT5sWFTgD82HAZSc2FlPe2B19PYXMgg7v x+ihPhcyG89JDgvXWI7a8/XHCX6r0jMsx5NZSkQIZiYfGH2eeR/JZeo+RZBWFFfEudg2 AMHPX/fTsSRvxz5Tw/YBOcHBowV7KxGfQ60qiHym0h2BeKDsL0hi7d+Vg99QMlcGXb5g 8n9YPmxsH8Vb2gAgPep8SJ/Mm1xLtBHroQYT5ohHHGnJCItpUZIFQn297QOnQVIPvnNa sR1A== MIME-Version: 1.0 X-Received: by 10.224.182.79 with SMTP id cb15mr8276131qab.48.1374055020507; Wed, 17 Jul 2013 02:57:00 -0700 (PDT) Received: by 10.49.127.231 with HTTP; Wed, 17 Jul 2013 02:57:00 -0700 (PDT) Date: Wed, 17 Jul 2013 11:57:00 +0200 Message-ID: Subject: ALTQ support for octe driver From: Daniel Engberg To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Jul 2013 09:57:01 -0000 Hi, Thanks to the hard work by FreeBSD's Cavium developers and the community we now have support for the EdgeRouter Lite boxes in -CURRENT and they're working quite well. Since the devs are bit busy with other projects I though I'd put up an open request of making the octe driver ALTQ aware. This would be a very nice addition to a cheap FreeBSD firewall/gateway that performs well overall. Unfortunately I'm not able to do it myself due to lack of knowledge of the inner workings but it seems quite easy looking at the old patch archive over here: http://people.freebsd.org/~mlaier/ALTQ_driver/ . If needed I can on the other hand test patches. Thanks in advance Daniel Engberg From owner-freebsd-net@FreeBSD.ORG Wed Jul 17 11:09:08 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F371D763 for ; Wed, 17 Jul 2013 11:09:07 +0000 (UTC) (envelope-from mattmiller1@gmail.com) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by mx1.freebsd.org (Postfix) with ESMTP id BD9C8996 for ; Wed, 17 Jul 2013 11:09:07 +0000 (UTC) Received: by mail-qa0-f52.google.com with SMTP id bv4so1022526qab.4 for ; Wed, 17 Jul 2013 04:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=nVib6VymJt2rkMW/LJcptcY3/iFrovpdigEVJ0a0Dp4=; b=kvwF4JotPtau8Q8hPMcWYxCSdeDAsd0VgMB6Q3BBCzpRiE/KnyZzLCdz6IP9z1UNFm wpRM7G2nBzpCCXtcqbUvtcpexLUgtmvQmKCiGj4ziTvd4KjJ7RRV5J7RhQXl2Hh2T0dF wHjjkxJFzt1HlfzZ9eefPkpy1uZ6ZKeNQzq9o+rzs57BG9bhXjMCxw9rNpTU5fvPaJtc SyjtAY4eJFLW8+0MNnq1M+dN4T8u+DSnd725hkln0zvS/4ucQZABg1jzhPm0AWudkIcU O2znXgboGX8VvBF/cZ5esDlcCDxITcdroGLnlp+JsaD5vZW/lFDSShglE0cG3PXVKNFG sLHw== X-Received: by 10.229.140.6 with SMTP id g6mr1750790qcu.14.1374059346946; Wed, 17 Jul 2013 04:09:06 -0700 (PDT) MIME-Version: 1.0 Sender: mattmiller1@gmail.com Received: by 10.49.14.65 with HTTP; Wed, 17 Jul 2013 04:08:26 -0700 (PDT) From: Matt Miller Date: Wed, 17 Jul 2013 07:08:26 -0400 X-Google-Sender-Auth: ba5SYKKiksigElenhewyH0EffCs Message-ID: Subject: TCP Loopback Connections with the Same Src/Dest Port To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Jul 2013 11:09:08 -0000 Our system is based on FreeBSD 8.1. In some tests, we were having issues caused by connections of this form (more details below): TCP4 0 0 0/ 0/ 0 127.0.0.1.665 127.0.0.1.665 FIN_WAIT_1 TCP4 0 0 0/ 0/ 0 127.0.0.1.637 127.0.0.1.637 FIN_WAIT_1 TCP4 0 0 0/ 0/ 0 127.0.0.1.648 127.0.0.1.648 FIN_WAIT_1 Some questions we had: - Has anyone else ever seen these same src/dest address/port TCP connections created? Does anyone know of a legitimate reason why they should be allowed? - If there are no known use cases for this type of connection, does anyone have more context/insight on the design here: should this type of inpcb creation be prevented in the kernel or is it the application's responsibility to ensure it never creates this type of socket? For those interested, more details of the issue seen follow. The connection seems to get stuck in swi_net sending and receiving pure FIN/ACKs to itself: #12 0xffffffff804372ce in ip_output (m=0xffffff0003ccf300, opt=, ro=0xffffff8020c2b6a0, flags=0, imo=0x0, inp=0xffffff0019933968) at ../../../../sys/netinet/ip_output.c #13 0xffffffff804423dc in tcp_output (tp=0xffffff0019de2370) at ../../../../sys/netinet/tcp_output.c #14 0xffffffff8043ef5d in tcp_do_segment (m=0xffffff0019af1200, th=0x100200, so=0xffffff011ac59570, tp=0xffffff0019de2370, drop_hdrlen=52, tlen=0, iptos=0 '\000', ti_locked=3) at ../../../../sys/netinet/tcp_input.c #15 0xffffffff80440311 in tcp_input (m=0xffffff0019af1200, off0=) at ../../../../sys/netinet/tcp_input.c #16 0xffffffff8043530b in ip_input (m=0xffffff0019af1200) at ../../../../sys/netinet/ip_input.c #17 0xffffffff8040889f in netisr_process_workstream_proto (proto=, nwsp=) at ../../../../sys/net/netisr.c #18 swi_net (arg=0xffffffff80f59800) at ../../../../sys/net/netisr.c swi_net() just continues in this loop, ad nauseam: 759 while ((bits = nwsp->nws_pendingbits) != 0) { 760 while ((prot = ffs(bits)) != 0) { 761 prot--; 762 bits &= ~(1 << prot); 763 (void)netisr_process_workstream_proto(nwsp, prot); 764 } 765 } The tcp_output() being triggered in tcp_do_segment() in the case is the one show on line 2303 below: 2212 /* 2213 * In ESTABLISHED state: drop duplicate ACKs; ACK out of range 2214 * ACKs. If the ack is in the range 2215 * tp->snd_una < th->th_ack <= tp->snd_max 2216 * then advance tp->snd_una to th->th_ack and drop 2217 * data from the retransmission queue. If this ACK reflects 2218 * more up to date window information we update our window information. 2219 */ 2220 case TCPS_ESTABLISHED: 2221 case TCPS_FIN_WAIT_1: 2222 case TCPS_FIN_WAIT_2: 2223 case TCPS_CLOSE_WAIT: 2224 case TCPS_CLOSING: 2225 case TCPS_LAST_ACK: 2226 if (SEQ_GT(th->th_ack, tp->snd_max)) { 2227 TCPSTAT_INC(tcps_rcvacktoomuch); 2228 goto dropafterack; 2229 } ... 2234 if (SEQ_LEQ(th->th_ack, tp->snd_una)) { ... 2248 if (tlen == 0 && tiwin == tp->snd_wnd) { 2249 TCPSTAT_INC(tcps_rcvdupack); ... 2277 if (!tcp_timer_active(tp, TT_REXMT) || 2278 th->th_ack != tp->snd_una) 2279 tp->t_dupacks = 0; 2280 else if (++tp->t_dupacks > tcprexmtthresh || 2281 ((V_tcp_do_newreno || 2282 (tp->t_flags & TF_SACK_PERMIT)) && 2283 IN_FASTRECOVERY(tp))) { 2284 if ((tp->t_flags & TF_SACK_PERMIT) && 2285 IN_FASTRECOVERY(tp)) { 2286 int awnd; 2287 2288 /* 2289 * Compute the amount of data in flight first. 2290 * We can inject new data into the pipe iff 2291 * we have less than 1/2 the original window's 2292 * worth of data in flight. 2293 */ 2294 awnd = (tp->snd_nxt - tp->snd_fack) + 2295 tp->sackhint.sack_bytes_rexmit; 2296 if (awnd < tp->snd_ssthresh) { 2297 tp->snd_cwnd += tp->t_maxseg; 2298 if (tp->snd_cwnd > tp->snd_ssthresh) 2299 tp->snd_cwnd = tp->snd_ssthresh; 2300 } 2301 } else 2302 tp->snd_cwnd += tp->t_maxseg; 2303 (void) tcp_output(tp); 2304 goto drop; I've noticed that we don't yet have this patch in our code: http://svnweb.freebsd.org/base?view=revision&revision=239672 Which seems like it could be relevant here to the general case of both ends of the connection entering FIN_WAIT_1 at the same time and sending FIN/ACKs repeatedly (though our connections are a bizarre case of this where both ends of the connection are actually the same connection). Thanks, Matt From owner-freebsd-net@FreeBSD.ORG Wed Jul 17 12:01:44 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 440BE788 for ; Wed, 17 Jul 2013 12:01:44 +0000 (UTC) (envelope-from mailnull@mips.inka.de) Received: from mail-in-08.arcor-online.net (mail-in-08.arcor-online.net [151.189.21.48]) by mx1.freebsd.org (Postfix) with ESMTP id F2C5DBCD for ; Wed, 17 Jul 2013 12:01:43 +0000 (UTC) Received: from mail-in-19-z2.arcor-online.net (mail-in-19-z2.arcor-online.net [151.189.8.36]) by mx.arcor.de (Postfix) with ESMTP id 0E0F815C235 for ; Wed, 17 Jul 2013 14:01:37 +0200 (CEST) Received: from mail-in-16.arcor-online.net (mail-in-16.arcor-online.net [151.189.21.56]) by mail-in-19-z2.arcor-online.net (Postfix) with ESMTP id 0FFCC3F83F0 for ; Wed, 17 Jul 2013 14:01:37 +0200 (CEST) X-Greylist: Passed host: 94.217.103.182 X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-16.arcor-online.net D6B17827F Received: from lorvorc.mips.inka.de (dslb-094-217-103-182.pools.arcor-ip.net [94.217.103.182]) by mail-in-16.arcor-online.net (Postfix) with ESMTPS id D6B17827F for ; Wed, 17 Jul 2013 14:01:36 +0200 (CEST) Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.7/8.14.7) with ESMTP id r6HC1aGw015706 for ; Wed, 17 Jul 2013 14:01:36 +0200 (CEST) (envelope-from mailnull@lorvorc.mips.inka.de) Received: (from mailnull@localhost) by lorvorc.mips.inka.de (8.14.7/8.14.7/Submit) id r6HC1af0015705 for freebsd-net@freebsd.org; Wed, 17 Jul 2013 14:01:36 +0200 (CEST) (envelope-from mailnull) From: naddy@mips.inka.de (Christian Weisgerber) Subject: Re: sis(4) flow control Date: Wed, 17 Jul 2013 12:01:36 +0000 (UTC) Message-ID: References: <51DC1599.8040805@incore.de> <20130711002557.GA6697@michelle.cdnetworks.com> <51E1B8F0.5030100@incore.de> <20130714100347.GA1105@michelle.cdnetworks.com> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Jul 2013 12:01:44 -0000 Yonghyeon PYUN wrote: > msk(4) supported flow-control from day 1 with a hack and it was > re-implemented later with proper way such that it always announces > flow-control. However for other drivers(i.e vr(4)) that didn't > support the feature in the beginning, you have to explicitly enable > the feature. The decision was made to provide compatibility and to > not introduce POLA. Funny how POLA is different for different people. I'm completely surprised that flow control isn't enabled by default, and the fact that this differs between drivers is outright bizarre. The flowcontrol option is also not mentioned in the media type section of the drivers' man pages. Until I stumbled over this thread, I had no idea it existed. I just blindly tried # ifconfig nfe0 mediaopt flowcontrol on a machine here and, lo and behold, it is successfully enabled. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-net@FreeBSD.ORG Wed Jul 17 12:35:48 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DC8376B for ; Wed, 17 Jul 2013 12:35:48 +0000 (UTC) (envelope-from therion@ninth-art.de) Received: from mail.unix.io (mail.unix.io [IPv6:2001:41d0:2:83a5::2]) by mx1.freebsd.org (Postfix) with ESMTP id A189AD3C for ; Wed, 17 Jul 2013 12:35:48 +0000 (UTC) Received: from mail.unix.io (localhost [127.0.0.1]) by mail.unix.io (Postfix) with ESMTP id 665152083 for ; Wed, 17 Jul 2013 14:35:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=ninth-art.de; h=subject :from:reply-to:to:content-type:date:message-id:mime-version :content-transfer-encoding; s=mail2013; bh=/9VLU58AwED+CRalsZ4Ow CWPjSY=; b=h6Cbk5Bv4KSUltCZBpxgH6UV225wlp501Vzj+BH92ZyYup8yd03zt iPmI/G0O/bS5CJt1baOUe06T+Gfg132Kj1E2pOiAEfmlpS5cnkRFPhaON9fNFP+f +9ODj2tuCs607IgUHVgEY0iwr7r3cKYkfO8qe2GhckbeGBnV4ElqVM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=ninth-art.de; h=subject:from :reply-to:to:content-type:date:message-id:mime-version :content-transfer-encoding; q=dns; s=mail2013; b=oZQjYKftFR2+eGU SY8pgggNIs2h8aTiR2Fzt6OPFlwJvNh+Fn7GsnXrYMlT/ws5L7sE/k7+mBRtZ2SS 6pK47qHAdtZ6XIbOr7FQ0I/QoO3nQSkI64018BmndyTEUdIk5BWeQ9IRmqZL2182 2YUOSWIHGZWuS41g8vEtowGH/bG0= Received: from [192.168.2.4] (p4FE4F584.dip0.t-ipconnect.de [79.228.245.132]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unix.io (Postfix) with ESMTPSA id 4000C2082 for ; Wed, 17 Jul 2013 14:35:47 +0200 (CEST) Subject: IPv6 NDP, static subnet entries From: Georg Bege To: freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" Date: Wed, 17 Jul 2013 14:36:13 +0200 Message-ID: <1374064573.525.2.camel@atwork> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: therion@ninth-art.de List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 12:35:48 -0000 Hello FreeBSD users Im in need of proxying an NDP entry, due my bad provider using IPv6 bridging. My entire subnet is not routed correctly, however I managed to get it working with ndp -s proxy - sadly this doesnt work for an whole subnet but for a single IP. I need exacly this for an whole subnet, is it possible? Im using FreeBSD 8.3-RELEASE-p4 - I did crawl thru google a lil' bit also found some older entries where people did had the same kind of problem. Of course people telling me, change provider and so on - but for this server it is not possible at the moment. regards, -- Georg Bege From owner-freebsd-net@FreeBSD.ORG Wed Jul 17 15:37:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 657929FE for ; Wed, 17 Jul 2013 15:37:23 +0000 (UTC) (envelope-from sbremal@hotmail.com) Received: from dub0-omc2-s32.dub0.hotmail.com (dub0-omc2-s32.dub0.hotmail.com [157.55.1.171]) by mx1.freebsd.org (Postfix) with ESMTP id 0C6C394B for ; Wed, 17 Jul 2013 15:37:22 +0000 (UTC) Received: from DUB104-W57 ([157.55.1.137]) by dub0-omc2-s32.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Jul 2013 08:36:16 -0700 X-TMN: [THOZc9QN5r2m4MKSFdN26vUtMp6GcXLo] X-Originating-Email: [sbremal@hotmail.com] Message-ID: From: To: "freebsd-net@freebsd.org" Subject: WG111v3 + 'urtw' = status: no carrier Date: Wed, 17 Jul 2013 15:36:16 +0000 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jul 2013 15:36:16.0002 (UTC) FILETIME=[600E6620:01CE8303] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Jul 2013 15:37:23 -0000 Hello=0A= =0A= Just recently upgraded to 8.1 and installed the 'urtw' driver for my Netgea= r WG111v3 USB WLAN card. All fine=2C systems boots=2C WLAN card gets IP add= ress=2C network runs. And then suddenly network connection breaks down. And= never recovers. Only reboot helps.=0A= =0A= Apparently the WLAN connection moves from 'status: associated' to 'status: = no carrier' and stays stuck there.=0A= =0A= Is there any way to prevent this? (WLAN signal is OK=2C put the box next to= the AP to test.)=0A= =0A= Or=2C can you recommend a PCI/PCIe card that is proven to work reliably?=0A= =0A= =0A= Regards=0A= Balazs=0A= =0A= ---=0A= =0A= This is how it starts:=0A= =0A= nfe0: flags=3D8843 metric 0= mtu 1500=0A= =A0=A0=A0=A0=A0=A0=A0 options=3D8010b=0A= =A0=A0=A0=A0=A0=A0=A0 ether 00:26:18:91:13:bc=0A= =A0=A0=A0=A0=A0=A0=A0 media: Ethernet autoselect (none)=0A= =A0=A0=A0=A0=A0=A0=A0 status: no carrier=0A= lo0: flags=3D8049 metric 0 mtu 16384= =0A= =A0=A0=A0=A0=A0=A0=A0 options=3D3=0A= =A0=A0=A0=A0=A0=A0=A0 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2=0A= =A0=A0=A0=A0=A0=A0=A0 inet6 ::1 prefixlen 128=0A= =A0=A0=A0=A0=A0=A0=A0 inet 127.0.0.1 netmask 0xff000000=0A= =A0=A0=A0=A0=A0=A0=A0 nd6 options=3D3=0A= urtw0: flags=3D8843 metric = 0 mtu 2290=0A= =A0=A0=A0=A0=A0=A0=A0 ether 00:1b:2f:ce:e2:72=0A= =A0=A0=A0=A0=A0=A0=A0 media: IEEE 802.11 Wireless Ethernet autoselect mode = 11g=0A= =A0=A0=A0=A0=A0=A0=A0 status: associated=0A= wlan0: flags=3D8843 metric = 0 mtu 1500=0A= =A0=A0=A0=A0=A0=A0=A0 ether 00:1b:2f:ce:e2:72=0A= =A0=A0=A0=A0=A0=A0=A0 inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168= .1.255=0A= =A0=A0=A0=A0=A0=A0=A0 media: IEEE 802.11 Wireless Ethernet autoselect mode = 11g=0A= =A0=A0=A0=A0=A0=A0=A0 status: associated=0A= =A0=A0=A0=A0=A0=A0=A0 ssid "Le Quack" channel 6 (2437 MHz 11g) bssid 00:1e:= 2a:5e:25:70=0A= =A0=A0=A0=A0=A0=A0=A0 country US authmode WPA2/802.11i privacy ON deftxkey = UNDEF=0A= =A0=A0=A0=A0=A0=A0=A0 TKIP 3:128-bit txpower 0 bmiss 7 scanvalid 450 bgscan= bgscanintvl 300=0A= =A0=A0=A0=A0=A0=A0=A0 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS r= oaming MANUAL=0A= =0A= =0A= And this is how it gets broken and never recovers:=0A= =0A= nfe0: flags=3D8843 metric 0= mtu 1500=0A= =A0=A0=A0=A0=A0=A0=A0 options=3D8010b=0A= =A0=A0=A0=A0=A0=A0=A0 ether 00:26:18:91:13:bc=0A= =A0=A0=A0=A0=A0=A0=A0 media: Ethernet autoselect (none)=0A= =A0=A0=A0=A0=A0=A0=A0 status: no carrier=0A= lo0: flags=3D8049 metric 0 mtu 16384= =0A= =A0=A0=A0=A0=A0=A0=A0 options=3D3=0A= =A0=A0=A0=A0=A0=A0=A0 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2=0A= =A0=A0=A0=A0=A0=A0=A0 inet6 ::1 prefixlen 128=0A= =A0=A0=A0=A0=A0=A0=A0 inet 127.0.0.1 netmask 0xff000000=0A= =A0=A0=A0=A0=A0=A0=A0 nd6 options=3D3=0A= urtw0: flags=3D8c43 metric 0 mtu 2290=0A= =A0=A0=A0=A0=A0=A0=A0 ether 00:1b:2f:ce:e2:72=0A= =A0=A0=A0=A0=A0=A0=A0 media: IEEE 802.11 Wireless Ethernet autoselect mode = 11g=0A= =A0=A0=A0=A0=A0=A0=A0 status: associated=0A= wlan0: flags=3D8c43 metric 0 mtu 1500=0A= =A0=A0=A0=A0=A0=A0=A0 ether 00:1b:2f:ce:e2:72=0A= =A0=A0=A0=A0=A0=A0=A0 inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168= .1.255=0A= =A0=A0=A0=A0=A0=A0=A0 media: IEEE 802.11 Wireless Ethernet autoselect (auto= select)=0A= =A0=A0=A0=A0=A0=A0=A0 status: no carrier=0A= =A0=A0=A0=A0=A0=A0=A0 ssid "Le Quack" channel 6 (2437 MHz 11g)=0A= =A0=A0=A0=A0=A0=A0=A0 country US authmode WPA2/802.11i privacy ON deftxkey = UNDEF txpower 0=0A= =A0=A0=A0=A0=A0=A0=A0 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanid= le 250=0A= =A0=A0=A0=A0=A0=A0=A0 roam:rssi 7 roam:rate 5 protmode CTS roaming MANUAL = = From owner-freebsd-net@FreeBSD.ORG Wed Jul 17 15:56:36 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B1B4FE8D for ; Wed, 17 Jul 2013 15:56:36 +0000 (UTC) (envelope-from feld@freebsd.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8B1E1A3C for ; Wed, 17 Jul 2013 15:56:36 +0000 (UTC) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 1D7C421714 for ; Wed, 17 Jul 2013 11:56:35 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Wed, 17 Jul 2013 11:56:35 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=q0X2YfZtHMBDMwj27m/SsXA3c3I=; b=Bna 19Ukk65Y4wBB1qZVn4jjDP0uaM+tGBMUb2MuOd1lHfxWZbKrXTg0XjmoJ6Sqcyck Bjh8yBjAuVayqJ1Z8bgnYklMrcV4n7gOr8d2zz+zXxwwJmO4rk6hu86wZgfmyL9L ThZkLVioU+JqgMufhaGS0yu+R1VC0O3NwXo9N2iA= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 00C72B00003; Wed, 17 Jul 2013 11:56:34 -0400 (EDT) Message-Id: <1374076594.21538.140661256769313.776F0A73@webmail.messagingengine.com> X-Sasl-Enc: XLozvuPHY41umEXrugrcvxvVRQDoT7mdOIHxZA0s6LEN 1374076594 From: Mark Felder To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-5a449c7a In-Reply-To: References: Subject: Re: WG111v3 + 'urtw' = status: no carrier Date: Wed, 17 Jul 2013 10:56:34 -0500 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Jul 2013 15:56:36 -0000 On Wed, Jul 17, 2013, at 10:36, sbremal@hotmail.com wrote: > Hello > > Just recently upgraded to 8.1 and installed the 'urtw' driver for my > Netgear WG111v3 USB WLAN card. Is there a reason why you specifically upgraded to 8.1 instead of choosing 8.3 or 8.4? FreeBSD 8.1 has been EoL since July 31 2013. This may very well have been fixed in a subsequent release. From owner-freebsd-net@FreeBSD.ORG Wed Jul 17 16:06:27 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4171417A; Wed, 17 Jul 2013 16:06:27 +0000 (UTC) (envelope-from sbremal@hotmail.com) Received: from dub0-omc4-s20.dub0.hotmail.com (dub0-omc4-s20.dub0.hotmail.com [157.55.2.95]) by mx1.freebsd.org (Postfix) with ESMTP id DC85EABF; Wed, 17 Jul 2013 16:06:26 +0000 (UTC) Received: from DUB104-W13 ([157.55.2.71]) by dub0-omc4-s20.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Jul 2013 09:05:18 -0700 X-TMN: [a4FqAqGt4p3UjTOFwuKKob90L9xz1ZFU] X-Originating-Email: [sbremal@hotmail.com] Message-ID: From: To: Mark Felder , "freebsd-net@freebsd.org" Subject: RE: WG111v3 + 'urtw' = status: no carrier Date: Wed, 17 Jul 2013 16:05:18 +0000 Importance: Normal In-Reply-To: <1374076594.21538.140661256769313.776F0A73@webmail.messagingengine.com> References: , <1374076594.21538.140661256769313.776F0A73@webmail.messagingengine.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jul 2013 16:05:18.0725 (UTC) FILETIME=[6ECCD350:01CE8307] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Jul 2013 16:06:27 -0000 To make the smallest upgrade possible and minimize potential reconfig issue= s etc. 8.1 was the first release supporting WG111v3.=0A= =0A= Could give a try with 8.4 if there was any major fix to WPA and WLAN driver= s since 8.1? With minor version upgrade there should be no change to instal= led ports etc.=2C correct?=0A= =0A= Still the other quesion: What is the WLAN (PCI/PCIe) card most people use H= APPILY in FreeBSD? Support for 802.11n would not be bad.=0A= =0A= =0A= Cheers=0A= Balazs=0A= =0A= ----------------------------------------=0A= > From: feld@freebsd.org=0A= > To: freebsd-net@freebsd.org=0A= > Subject: Re: WG111v3 + 'urtw' =3D status: no carrier=0A= > Date: Wed=2C 17 Jul 2013 10:56:34 -0500=0A= >=0A= > On Wed=2C Jul 17=2C 2013=2C at 10:36=2C sbremal@hotmail.com wrote:=0A= >> Hello=0A= >>=0A= >> Just recently upgraded to 8.1 and installed the 'urtw' driver for my=0A= >> Netgear WG111v3 USB WLAN card.=0A= >=0A= > Is there a reason why you specifically upgraded to 8.1 instead of=0A= > choosing 8.3 or 8.4? FreeBSD 8.1 has been EoL since July 31 2013. This=0A= > may very well have been fixed in a subsequent release.=0A= > _______________________________________________=0A= > freebsd-net@freebsd.org mailing list=0A= > http://lists.freebsd.org/mailman/listinfo/freebsd-net=0A= > To unsubscribe=2C send any mail to "freebsd-net-unsubscribe@freebsd.org" = = From owner-freebsd-net@FreeBSD.ORG Wed Jul 17 16:26:55 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7AB8691A for ; Wed, 17 Jul 2013 16:26:55 +0000 (UTC) (envelope-from feld@freebsd.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 548F7BC8 for ; Wed, 17 Jul 2013 16:26:55 +0000 (UTC) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id ABC1F20FE2; Wed, 17 Jul 2013 12:26:54 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Wed, 17 Jul 2013 12:26:54 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=qgfUGmn8xTlk8sYH7PZw6u5gn1I=; b=M3f PKFuD6RuUtNOyalBW/ouOt2Cki0EoIRG6W2QC4xSEcYwrCcq/9rJrN1yMY7cGEgj ZoWuhRwdA8q6w997rHDrKHg3FDTxvdOqgipp0RuvnMcdIvSlqbFI5uj4MuJAEJSi On3X3sdfU6qrZrR8ZaNvvILtF3payijNBfWE+ZAg= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 82424B00003; Wed, 17 Jul 2013 12:26:54 -0400 (EDT) Message-Id: <1374078414.32469.140661256780077.0A403C24@webmail.messagingengine.com> X-Sasl-Enc: 620vwBVdQdhpQ1jv6FvlqEog8ZXq4ACzeAH9pDPakF3C 1374078414 From: Mark Felder To: sbremal@hotmail.com, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-5a449c7a In-Reply-To: References: <1374076594.21538.140661256769313.776F0A73@webmail.messagingengine.com> Subject: Re: WG111v3 + 'urtw' = status: no carrier Date: Wed, 17 Jul 2013 11:26:54 -0500 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Jul 2013 16:26:55 -0000 On Wed, Jul 17, 2013, at 11:05, sbremal@hotmail.com wrote: > To make the smallest upgrade possible and minimize potential reconfig > issues etc. 8.1 was the first release supporting WG111v3. > > Could give a try with 8.4 if there was any major fix to WPA and WLAN > drivers since 8.1? With minor version upgrade there should be no change > to installed ports etc., correct? > 8.4 should be compatible with all binaries compiled against 8.1. Please let us know if you find something that doesn't work, but the goal has always been to keep compatibility within the same major release. > Still the other quesion: What is the WLAN (PCI/PCIe) card most people use > HAPPILY in FreeBSD? Support for 802.11n would not be bad. > Unfortunately I don't have any suggestions for this. You can see the changelogs for the driver in the links below. head: http://svnweb.freebsd.org/base/head/sys/dev/usb/wlan/if_urtw.c?view=log 9.1: http://svnweb.freebsd.org/base/release/9.1.0/sys/dev/usb/wlan/if_urtw.c?view=log 8.4: http://svnweb.freebsd.org/base/release/8.4.0/sys/dev/usb/wlan/if_urtw.c?view=log 8.1: http://svnweb.freebsd.org/base/release/8.1.0/sys/dev/usb/wlan/if_urtw.c?view=log As you can see, 8.4 has a couple commits 8.1 didn't have, 9.1 a few more, and some recent work in head (-CURRENT) imported from OpenBSD. I don't know if any of those fixes are relevant to your situation, but it might be worth testing to see. From owner-freebsd-net@FreeBSD.ORG Wed Jul 17 17:22:06 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A1478804 for ; Wed, 17 Jul 2013 17:22:06 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 25A59ED3 for ; Wed, 17 Jul 2013 17:22:05 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.7/8.14.7/ALCHEMY.FRANKEN.DE) with ESMTP id r6HHLwSx052207; Wed, 17 Jul 2013 19:21:58 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.7/8.14.7/Submit) id r6HHLwXT052206; Wed, 17 Jul 2013 19:21:58 +0200 (CEST) (envelope-from marius) Date: Wed, 17 Jul 2013 19:21:58 +0200 From: Marius Strobl To: Christian Weisgerber Subject: Re: sis(4) flow control Message-ID: <20130717172158.GA52088@alchemy.franken.de> References: <51DC1599.8040805@incore.de> <20130711002557.GA6697@michelle.cdnetworks.com> <51E1B8F0.5030100@incore.de> <20130714100347.GA1105@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Jul 2013 17:22:06 -0000 On Wed, Jul 17, 2013 at 12:01:36PM +0000, Christian Weisgerber wrote: > Yonghyeon PYUN wrote: > > > msk(4) supported flow-control from day 1 with a hack and it was > > re-implemented later with proper way such that it always announces > > flow-control. However for other drivers(i.e vr(4)) that didn't > > support the feature in the beginning, you have to explicitly enable > > the feature. The decision was made to provide compatibility and to > > not introduce POLA. > > Funny how POLA is different for different people. I'm completely > surprised that flow control isn't enabled by default, and the fact > that this differs between drivers is outright bizarre. For the vast majority of MAC drivers taking advantage of mii(4), flow control just wasn't available before the latter grew proper support for it. For POLA reasons, it was decided to not change that situation and, thus, to not suddenly announce flow support in environments that might not be properly configured and/or tested for it. The only exception in that regard are five drivers that previously implemented hacks to support flow control and whose default was changed to off in order to be consistent with the remainder while FreeBSD 9 was -current (see the 20101114 UPDATING entry). For drivers like em(4) that don't take advantage of mii(4) the default and ways to configure flow control still varies, though. > > The flowcontrol option is also not mentioned in the media type > section of the drivers' man pages. It doesn't make sense to document media types in the man pages of MAC drivers employing mii(4) in the first place and we should have something like a common media.4 for that. For one, having such a section in all of these drivers is plain redundant. Second, technically it just doesn't belong there; PHY rather than MAC drivers are at the layer dealing with network media. For example, a Gigabit Ethernet MAC might be equipped with a PHY only capable of Fast Ethernet, not supporting flow control or fibre in addition or instead of copper media (which are all examples from reality). Saying that a specific MAC driver "supports" certain media is just outright misleading in such cases. Marius From owner-freebsd-net@FreeBSD.ORG Wed Jul 17 21:23:43 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E2E5A723; Wed, 17 Jul 2013 21:23:42 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id 0C8B1C4B; Wed, 17 Jul 2013 21:23:41 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id ec20so1933387lab.27 for ; Wed, 17 Jul 2013 14:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=7ijMOqhSiXP0ybvBOjuD7kiwU4wgW/YXXamP5x30TqI=; b=RL7NeGRtX+s26IH40qUlH7Mc4TpbBAtRBqzhO8U0tEw0G2rlQjyaDFY6UyPYwng1G8 2GfYqo3LXGH26ENz2DfPJQDDOmtOJp8DnyHRAO8RyDJFnqO9BNazfNTivCE1drBZhFJb 08uyx/nJN2rjMdHV5maClFekGk7axo3cTrtCRdqXqYAxhR3Byv7V8yfDjbH6e+KXcxWp RYyITBrvF+9SOU5o4veZRj66eYOYkIOC9XWeRyOpU80vi6a5wYL1JT2Oy+QpVmeznSrq vPGjxaJ+Dwcm3RyA/Akr1XWvxN9S4Vz0B7W6A9StdGgpXz/IxnP9LZidwCfry8Xq1AA1 ya+Q== X-Received: by 10.112.201.138 with SMTP id ka10mr3975791lbc.72.1374096220987; Wed, 17 Jul 2013 14:23:40 -0700 (PDT) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPSA id 8sm3412368lbq.4.2013.07.17.14.23.38 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 17 Jul 2013 14:23:39 -0700 (PDT) Sender: Mikolaj Golub Date: Thu, 18 Jul 2013 00:23:37 +0300 From: Mikolaj Golub To: John Baldwin Subject: Re: bind error when using SO_REUSEPORT(implies SO_REUSEADDR) Message-ID: <20130717212336.GA35489@gmail.com> References: <1331855948.3317.17.camel@powernoodle-l7.corp.yahoo.com> <1331856466.3317.18.camel@powernoodle-l7.corp.yahoo.com> <201307161112.46116.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201307161112.46116.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Jul 2013 21:23:43 -0000 On Tue, Jul 16, 2013 at 11:12:46AM -0400, John Baldwin wrote: > On Thursday, March 15, 2012 8:07:46 pm Sean Bruno wrote: > > On Thu, 2012-03-15 at 16:59 -0700, Sean Bruno wrote: > > > Hey, I just found a bind bug ticket in my queue about bind. I noted > > > that on stable/6 stable/7 stable/9 & head the referenced code "fails". > > > > > > It seems that this is a problem, but I have no idea if its a real > > > problem or not. Our devs think it is. Anyway, here is a code snippet > > > to show the failure in bind. On linux/solaris this does not fail. > > > > > > http://people.freebsd.org/~sbruno/bind_test.c > > > > > > simple compile with gcc -o test test.c and run as normal user. > > > > > > Sean > > > > > > > this is bind() not bind ... :-) > > Did the recent commit to HEAD fix this btw? As for me, bind_test.c does not expose any bug in freebsd, it only shows different behavior for freebsd and linux. On freebsd the test output is: serversock addr is 127.0.0.1:27539 dup bind: Address already in use This error was expected, tried to bind to used addr/port BUG: binding duplicate socket to server port succeeded dup2sock addr is 0.0.0.0:27539 overlapping explicit bind to same port number succeeded without SO_REUSEPORT listen succeeded after explicitly overlapping port bind autosock addr is 0.0.0.0:27539 bug triggered, port number conflict on sockets without SO_REUSEPORT listen succeded after implicitly overlapping port bind So, the first socket (serversock) is bound to the loopback address, then it tries some combinations of binding the second socket to the same port but to the wildcard address. When SO_REUSEADDR socket option is set, binding to the wildcard address succeeds for freebsd (and fails for linux). They call this a bug in freebsd, but this is well known and expected behavior (see e.g. Stevens' TCP/IP Illustrated Vol1). Or I missed the test's point? -- Mikolaj Golub From owner-freebsd-net@FreeBSD.ORG Wed Jul 17 21:45:52 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E8818175 for ; Wed, 17 Jul 2013 21:45:52 +0000 (UTC) (envelope-from jose.fontaine0527@orange.fr) Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) by mx1.freebsd.org (Postfix) with ESMTP id 8FE70D57 for ; Wed, 17 Jul 2013 21:45:51 +0000 (UTC) Received: from [14.99.19.95] ([14.99.19.95]) by mwinf5d28 with ME id 1Zjs1m004234l1203Zliaw; Wed, 17 Jul 2013 23:45:44 +0200 Message-ID: <7aad397f7d20099eb92c37c259d155d8@mwinf5d28.me-wanadoo.net> Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Description: Mail message body Subject: Dear User To: freebsd-net@freebsd.org From: "Admin" Date: Thu, 18 Jul 2013 03:15:36 +0530 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: hddata@postbox.lt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 21:45:53 -0000 Dear User, This mail is to inform all our Subscriber that we will be maintaining and = upgrading our website in a couple of days from now.As a Subscriber you are = thereby advice to send the below information: Email: User name: Password: To avoid deleting your valid account from our DATABASE. Pleaseunderstand th= at we doing this maintenance to create space for new subscribers.Failure to= do this will immediately render your email address deactivated from our da= tabase . ADMIN WEBMAIL SECURITY From owner-freebsd-net@FreeBSD.ORG Wed Jul 17 21:52:28 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E4AF45EF; Wed, 17 Jul 2013 21:52:28 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by mx1.freebsd.org (Postfix) with ESMTP id 594C5DC2; Wed, 17 Jul 2013 21:52:28 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id ey16so2519898wid.4 for ; Wed, 17 Jul 2013 14:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=woAxTe8kXGYGzU9S4BWD8gxepgFQ1mGMZUWzlNH4NHc=; b=rgCqI+sJxhOpzQmQC9o3HFPOJR4HXxZp0QVro0v6/zIY5LtTiC4wjugPchq3ugKj5K Fsfn776dBuWQXiDEGgkV6UiM70VGZE1xQHuV+fHQ9LlZ3f0TcqlGAhZEs+0RwfrFvs+Z NB8xlSPqqFggiGOJUXZG0ym8c0yPPJkNZdjp/5Ojs+6VInbzpioR/iV1F68e6eGKWFJP i+H4Ve4Z3S/LGHpp8kNunvVUUiazQy35iKSwZleDujmu2CLa4eXY5ft6m04eR08ZH7Fz DbGuDUx+fJQPo+PN/kde569gVw0dzGgGxiOKN2G5cdGmFQ8CNZaWL95oIS3KyvZyViwP vP3g== MIME-Version: 1.0 X-Received: by 10.180.20.116 with SMTP id m20mr6018615wie.46.1374097946712; Wed, 17 Jul 2013 14:52:26 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Wed, 17 Jul 2013 14:52:26 -0700 (PDT) In-Reply-To: <1374078414.32469.140661256780077.0A403C24@webmail.messagingengine.com> References: <1374076594.21538.140661256769313.776F0A73@webmail.messagingengine.com> <1374078414.32469.140661256780077.0A403C24@webmail.messagingengine.com> Date: Wed, 17 Jul 2013 14:52:26 -0700 X-Google-Sender-Auth: gohKxDvGc3JPgRa1H2rabMo2PZ0 Message-ID: Subject: Re: WG111v3 + 'urtw' = status: no carrier From: Adrian Chadd To: Mark Felder Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, sbremal@hotmail.com X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Jul 2013 21:52:29 -0000 The wifi improvements are going into -HEAD. _I_ have no plans to backport them to -9 as there's just too much changing/improving. So I hate to say it, but I think you're going to be short of luck. FreeBSD-10 needs testing sooner rather than later, so I do really suggest you just bite the bullet and try -HEAD. Please report back what does / doesn't work :) Thanks, -adrian From owner-freebsd-net@FreeBSD.ORG Thu Jul 18 14:32:10 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C8C30940; Thu, 18 Jul 2013 14:32:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id A52AC198; Thu, 18 Jul 2013 14:32:10 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DE497B982; Thu, 18 Jul 2013 10:32:09 -0400 (EDT) From: John Baldwin To: Mikolaj Golub Subject: Re: bind error when using SO_REUSEPORT(implies SO_REUSEADDR) Date: Thu, 18 Jul 2013 10:04:21 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <1331855948.3317.17.camel@powernoodle-l7.corp.yahoo.com> <201307161112.46116.jhb@freebsd.org> <20130717212336.GA35489@gmail.com> In-Reply-To: <20130717212336.GA35489@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201307181004.21844.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 18 Jul 2013 10:32:10 -0400 (EDT) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Jul 2013 14:32:10 -0000 On Wednesday, July 17, 2013 5:23:37 pm Mikolaj Golub wrote: > On Tue, Jul 16, 2013 at 11:12:46AM -0400, John Baldwin wrote: > > On Thursday, March 15, 2012 8:07:46 pm Sean Bruno wrote: > > > On Thu, 2012-03-15 at 16:59 -0700, Sean Bruno wrote: > > > > Hey, I just found a bind bug ticket in my queue about bind. I noted > > > > that on stable/6 stable/7 stable/9 & head the referenced code "fails". > > > > > > > > It seems that this is a problem, but I have no idea if its a real > > > > problem or not. Our devs think it is. Anyway, here is a code snippet > > > > to show the failure in bind. On linux/solaris this does not fail. > > > > > > > > http://people.freebsd.org/~sbruno/bind_test.c > > > > > > > > simple compile with gcc -o test test.c and run as normal user. > > > > > > > > Sean > > > > > > > > > > this is bind() not bind ... :-) > > > > Did the recent commit to HEAD fix this btw? > > As for me, bind_test.c does not expose any bug in freebsd, it only > shows different behavior for freebsd and linux. > > On freebsd the test output is: > > serversock addr is 127.0.0.1:27539 > dup bind: Address already in use > This error was expected, tried to bind to used addr/port > BUG: binding duplicate socket to server port succeeded > dup2sock addr is 0.0.0.0:27539 > overlapping explicit bind to same port number succeeded without SO_REUSEPORT > listen succeeded after explicitly overlapping port bind > autosock addr is 0.0.0.0:27539 > bug triggered, port number conflict on sockets without SO_REUSEPORT > listen succeded after implicitly overlapping port bind > > So, the first socket (serversock) is bound to the loopback address, > then it tries some combinations of binding the second socket to the > same port but to the wildcard address. When SO_REUSEADDR socket option > is set, binding to the wildcard address succeeds for freebsd (and > fails for linux). > > They call this a bug in freebsd, but this is well known and expected > behavior (see e.g. Stevens' TCP/IP Illustrated Vol1). > > Or I missed the test's point? No, that is probably true. I wasn't sure if it was a bug or not when Sean originally posted it. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Jul 18 15:39:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D679EE48; Thu, 18 Jul 2013 15:39:02 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 7C6726A5; Thu, 18 Jul 2013 15:39:02 +0000 (UTC) Received: by mail-qe0-f42.google.com with SMTP id s14so1884754qeb.1 for ; Thu, 18 Jul 2013 08:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=icF1Bf3J2Ipxlm2KEU9JOCkk7lPUeDaniI/kcoCw6IQ=; b=zfMKpiBGQH/GyvX3v0ttQ1DRyqOkSpc26tgWhySavYGnmfITHX+W/rL+vWvzerHKmV g21nFr0TF0aVd5sk0m7teEO0rIlvfobC2ZPbn2oHiZfpSBSiE10qw92MhUBuZ8qlo1Wm 75my73/uuqr+TwCm74vRXCUSSSbo+OGAYarB74id8sincX3+XeY7LBR1d/UvfeZ5lQ5Y 0bQxIlY9b0U2AHJopmr5x8vEIaY/V8N7Azmp1Nc8TIRPeibxu+LJkDU7xaJoveyurP0u 0lvaygC6WNFCDsne40S0s9bGMaYheQlkrx+LnU3DOzrYAIQWYWz+057k5qX7Y4DYsh+6 meJw== MIME-Version: 1.0 X-Received: by 10.224.122.66 with SMTP id k2mr14619432qar.47.1374161942000; Thu, 18 Jul 2013 08:39:02 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.49.35.84 with HTTP; Thu, 18 Jul 2013 08:39:01 -0700 (PDT) Date: Thu, 18 Jul 2013 17:39:01 +0200 X-Google-Sender-Auth: SwoMlP39CdiFpGsTHACONQxUpMU Message-ID: Subject: Atheros AR9002U-2NG based TP-LINK TL-WN822N Ver:2.0 - adding support to FreeBSD From: CeDeROM To: "freebsd-usb@FreeBSD.org" , freebsd-net@freebsd.org, freebsd-hardware@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Jul 2013 15:39:02 -0000 Hello :-) I have just bought USB WiFi b/g/n dongle from TP-LINK model TL-WN822B Ver:2.0 [1] which use following chipsets: Atheros AR9002U-2NG, Atheros AR7010, Atheros AR9287. It looks nice bacuse it cost ~20EUR it has external antennas and has very good opinions. Now, I start to think that finding Ver:3.0 based on RTL8192CU [2] might be a better choice..? Still I consider Atheros to be a better solution than Realtek..? I have made simple modification of /usr/src/sys/dev/usb/usbdevs and /usr/src/sys/dev/usb/wlan/if_uath.c to get it recognised, but uath driver seems to only support AR5005UG according to manpage. Is there any known driver to operate AR9002 chips? Here is what dmesg shows after my kernel modification/rebuild: ugen1.3: at usbus1 uath0: on usbus1 uath0: could not allocate USB transfers, err=USB_ERR_NO_PIPE device_attach: uath0 attach returned 12 So it looks this driver will not operate with this chipset..? Any hints appreciated! :-) Tomek [1] http://wikidevi.com/wiki/TP-LINK_TL-WN822N_v2 [2] http://wikidevi.com/wiki/TP-LINK_TL-WN822N_v3 -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-net@FreeBSD.ORG Thu Jul 18 17:06:42 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3E074B3F; Thu, 18 Jul 2013 17:06:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by mx1.freebsd.org (Postfix) with ESMTP id 7F62BB9D; Thu, 18 Jul 2013 17:06:41 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id b12so3155716wgh.7 for ; Thu, 18 Jul 2013 10:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=aAivkRBM66BfJK6pIGUJ2cx2n9RTIeRBR/yFc6FG5yA=; b=jGkHqGOvJ1fcU9o1ZopUtiWo/tWppBTv8E2tCPf9orCyJPrD9ZqtDpT6iYptoiHsbC ZotvJmOmwNYK9rmZu9Eqx5ovXlM9j3MPW6pfuNJih3IMzDOO3kXBNzQ90HfiGCf2u7PM rKhTW2kGcv5g4lgXGxm7nYkkNBS6dP7rSqPWrJWD65xpLdHKgm0TFBHcKvO0mxjqvCim atsjjmjvtcRYvS3gSWhdle42nvdbzDeVr1BMbOsux57E8Y4JLzLeemUiBmavQ3tOJaeF aRhl87gZTx/BN9oMB8zYGPzCpWix8GdMfXjmIBA32evqAUb7gKO+Dlv9kf18tMUAS0mF 9rbQ== MIME-Version: 1.0 X-Received: by 10.194.11.72 with SMTP id o8mr9510653wjb.0.1374167200553; Thu, 18 Jul 2013 10:06:40 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Thu, 18 Jul 2013 10:06:40 -0700 (PDT) In-Reply-To: References: Date: Thu, 18 Jul 2013 10:06:40 -0700 X-Google-Sender-Auth: HnmeY0EcbnSm-lW2yJR1YmP1YHU Message-ID: Subject: Re: Atheros AR9002U-2NG based TP-LINK TL-WN822N Ver:2.0 - adding support to FreeBSD From: Adrian Chadd To: CeDeROM Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, "freebsd-usb@FreeBSD.org" , freebsd-hardware@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Jul 2013 17:06:42 -0000 It's not uath. It's a different beast entirely. Basically, it requires someone with USB clue to write the USB glue between the ath(4) and ath_hal(4) code and the USB interface. Look at what ath9k_htc implements. It uses most of ath9k, but it implements a data/control pipe over USB and some commands to tell the firmware to do things (like new/delete client, etc.) -adrian On 18 July 2013 08:39, CeDeROM wrote: > Hello :-) > > I have just bought USB WiFi b/g/n dongle from TP-LINK model TL-WN822B > Ver:2.0 [1] which use following chipsets: Atheros AR9002U-2NG, Atheros > AR7010, Atheros AR9287. It looks nice bacuse it cost ~20EUR it has > external antennas and has very good opinions. Now, I start to think > that finding Ver:3.0 based on RTL8192CU [2] might be a better > choice..? Still I consider Atheros to be a better solution than > Realtek..? > > I have made simple modification of /usr/src/sys/dev/usb/usbdevs and > /usr/src/sys/dev/usb/wlan/if_uath.c to get it recognised, but uath > driver seems to only support AR5005UG according to manpage. Is there > any known driver to operate AR9002 chips? > > Here is what dmesg shows after my kernel modification/rebuild: > > ugen1.3: at usbus1 > uath0: on usbus1 > uath0: could not allocate USB transfers, err=USB_ERR_NO_PIPE > device_attach: uath0 attach returned 12 > > So it looks this driver will not operate with this chipset..? > > Any hints appreciated! :-) > Tomek > > [1] http://wikidevi.com/wiki/TP-LINK_TL-WN822N_v2 > [2] http://wikidevi.com/wiki/TP-LINK_TL-WN822N_v3 > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > _______________________________________________ > freebsd-usb@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-usb > To unsubscribe, send any mail to "freebsd-usb-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Jul 18 17:22:31 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AD054179; Thu, 18 Jul 2013 17:22:31 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-qe0-x232.google.com (mail-qe0-x232.google.com [IPv6:2607:f8b0:400d:c02::232]) by mx1.freebsd.org (Postfix) with ESMTP id 405F5C4F; Thu, 18 Jul 2013 17:22:31 +0000 (UTC) Received: by mail-qe0-f50.google.com with SMTP id f6so1940255qej.9 for ; Thu, 18 Jul 2013 10:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=m/G9MZY9uD2PdhLs8QylrpcowIagkgI/Oqv8Ny3B5Ho=; b=h7OKsb65ASlEhMGuqx047bJI7tCCcXNnrZiGSjdy+R9aFNs2HfAqyngtYIooSBWn0D VKARGajtlQTD57v2MgUuIyBR32ntAcE4RVFD1+H40/xvSYeeE2tY1S1Hs9ZAxgFJX3Lm qboILDM46suCXyLaTTatMrAYoYw+JdKFdQk+da9LJgUAvfslPa1uJJDm7WS4E99/1LO0 x4aUIFnn471tsJbulUDaRbi7GFk5QEkuF+U4z2UJGNEX9QeqUA0qtJwaDfT5ZigmQ6sK GP6f7COtNxyeJPaeSNF/+mx52eLBbQqaj7XWjz1SUS97DhUGj5fxcl/fgtUGfeEPjp/h HIkw== MIME-Version: 1.0 X-Received: by 10.224.74.212 with SMTP id v20mr14810654qaj.65.1374168150405; Thu, 18 Jul 2013 10:22:30 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.49.35.84 with HTTP; Thu, 18 Jul 2013 10:22:30 -0700 (PDT) In-Reply-To: References: Date: Thu, 18 Jul 2013 19:22:30 +0200 X-Google-Sender-Auth: KlY461KKceKLLazhVDr91RrP9YY Message-ID: Subject: Re: Atheros AR9002U-2NG based TP-LINK TL-WN822N Ver:2.0 - adding support to FreeBSD From: CeDeROM To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org, "freebsd-usb@FreeBSD.org" , freebsd-hardware@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Jul 2013 17:22:31 -0000 On Thu, Jul 18, 2013 at 7:06 PM, Adrian Chadd wrote: > It's not uath. It's a different beast entirely. > > Basically, it requires someone with USB clue to write the USB glue > between the ath(4) and ath_hal(4) code and the USB interface. > > Look at what ath9k_htc implements. It uses most of ath9k, but it > implements a data/control pipe over USB and some commands to tell the > firmware to do things (like new/delete client, etc.) Yea, I have grepped the sources and that this chip seems to have already some support, but it needs some more glue to work over USB as you tell Adrian :-) Not sure if I can do this, but I can always try :D :D Be(a)st regards! :-) Tomek Cedro -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-net@FreeBSD.ORG Thu Jul 18 19:41:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 99EA9773; Thu, 18 Jul 2013 19:41:23 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 55C2B321; Thu, 18 Jul 2013 19:41:23 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id 8795F7A222; Thu, 18 Jul 2013 21:41:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 422168EF1E3; Thu, 18 Jul 2013 21:41:25 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-4BuTKpUsUI; Thu, 18 Jul 2013 21:41:23 +0200 (CEST) Received: from laptop015.hselasky.homeunix.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id 94B1B8EF1E2; Thu, 18 Jul 2013 21:41:23 +0200 (CEST) Message-ID: <51E8453E.60603@bitfrost.no> Date: Thu, 18 Jul 2013 21:42:54 +0200 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130522 Thunderbird/17.0.6 MIME-Version: 1.0 To: CeDeROM Subject: Re: Atheros AR9002U-2NG based TP-LINK TL-WN822N Ver:2.0 - adding support to FreeBSD References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, "freebsd-usb@FreeBSD.org" , freebsd-hardware@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Jul 2013 19:41:23 -0000 On 07/18/13 17:39, CeDeROM wrote: > Hello :-) > Hi, The atheros driver has the endpoint numbers hardcoded. I recommend using relative indexes for each interface. Should be trivial to fix. I'll leave that for the author of the uath driver. --HPS > ugen1.3: at usbus1 > uath0: on usbus1 > uath0: could not allocate USB transfers, err=USB_ERR_NO_PIPE > device_attach: uath0 attach returned 12 > > So it looks this driver will not operate with this chipset..? > > Any hints appreciated! :-) > Tomek > > [1] http://wikidevi.com/wiki/TP-LINK_TL-WN822N_v2 > [2] http://wikidevi.com/wiki/TP-LINK_TL-WN822N_v3 > From owner-freebsd-net@FreeBSD.ORG Thu Jul 18 21:30:49 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6B6386EA for ; Thu, 18 Jul 2013 21:30:49 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from winston.madpilot.net (winston.madpilot.net [78.47.75.155]) by mx1.freebsd.org (Postfix) with ESMTP id E92BDA3C for ; Thu, 18 Jul 2013 21:30:48 +0000 (UTC) Received: from winston.madpilot.net (localhost [127.0.0.1]) by winston.madpilot.net (Postfix) with ESMTP id 3bx7n31nSwzFTc2; Thu, 18 Jul 2013 23:30:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at madpilot.net Received: from winston.madpilot.net ([127.0.0.1]) by winston.madpilot.net (winston.madpilot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DABaLn7MptCC; Thu, 18 Jul 2013 23:30:45 +0200 (CEST) Received: from tommy.madpilot.net (micro.madpilot.net [88.149.173.206]) by winston.madpilot.net (Postfix) with ESMTPSA; Thu, 18 Jul 2013 23:30:45 +0200 (CEST) Message-ID: <51E85E85.1040601@madpilot.net> Date: Thu, 18 Jul 2013 23:30:45 +0200 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130627 Thunderbird/17.0.7 MIME-Version: 1.0 To: pyunyh@gmail.com Subject: Re: re0 not working at boot on -CURRENT References: <51DC726D.6040601@madpilot.net> <20130710070431.GE2753@michelle.cdnetworks.com> <51DD9E15.7070609@madpilot.net> In-Reply-To: <51DD9E15.7070609@madpilot.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Jul 2013 21:30:49 -0000 On 07/10/13 19:47, Guido Falsi wrote: > On 07/10/13 09:04, Yonghyeon PYUN wrote: >> On Tue, Jul 09, 2013 at 10:28:29PM +0200, Guido Falsi wrote: >>> Hi, >>> >>> I have a PC with an integrate re ethernet interface, pciconf identifies >>> it like this: >>> >>> re0@pci0:3:0:0: class=0x020000 card=0x11c01734 chip=0x816810ec rev=0x07 >>> hdr=0x00 >>> >>> I'm running FreeBSD current r252261. >>> >>> As stated in the subject after boot the interface does not work >>> correctly. >>> >>> Using tcpdump on another host I noticed that packets (ICMP echo requests >>> for example) do get sent, and replies generated by the other host, but >>> the kernel does not seem to see them. Except that every now and then >>> some packet does get to the system. >>> >>> I'm seeing packet 7, 27, 47, 66, 86, 106, 125, 144, 164, 183 and so on >>> from a ping which has been running for some time. Just about one every >>> twenty. Some pattern is showing up. >>> >>> this is the output of ifconfig re0 after boot: >>> >>> re0: flags=8843 metric 0 mtu >>> 1500 >>> >>> options=8209b >>> >>> ether 00:19:99:f8:d3:0b >>> inet 172.24.42.13 netmask 0xffffff00 broadcast 172.24.42.255 >>> inet6 fe80::219:99ff:fef8:d30b%re0 prefixlen 64 scopeid 0x2 >>> nd6 options=29 >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> >>> If I just touch any interface flag with ifconfig, anyone, tso, -txcsum >>> -rxcsum, it starts working flawlessly. It keeps working also if I >>> perform the opposite operation with ifconfig afterwards, so it is not >>> the flag itself fixing it. >>> >>> This is an ifconfig after performing this exercise(it's the same, since >>> I disabled txcsum and reactivated it in this instance): >>> >>> re0: flags=8843 metric 0 mtu >>> 1500 >>> >>> options=8209b >>> >>> ether 00:19:99:f8:d3:0b >>> inet 172.24.42.13 netmask 0xffffff00 broadcast 172.24.42.255 >>> inet6 fe80::219:99ff:fef8:d30b%re0 prefixlen 64 scopeid 0x2 >>> nd6 options=29 >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> >>> I don't know much about FreeBSD network drivers so i can't make theories >>> about this. I hope someone has an idea what the problem could be. >>> >>> I'm available for any further information needed, test, experiment and >>> so on. >> >> Could you show me dmesg output(re(4) and rgephy(4) only)? > > re0: port > 0xd000-0xd0ff mem 0xf2104000-0xf2104fff,0xf2100000-0xf2103fff irq 17 at > device 0.0 on pci3 > re0: Using 1 MSI-X message > re0: turning off MSI enable bit. > re0: Chip rev. 0x2c800000 > re0: MAC rev. 0x00000000 > re0: Ethernet address: 00:19:99:f8:d3:0b > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, > 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, > 1000baseT-FDX-flow-master, auto, auto-flow > > Also, I'm loading this as a module, but, for as much as I know, this > should not make any difference. > > >> Did it ever work or you see the issue only on CURRENT? > > Never worked on this machine (I own it since the last days of February). > > I only installed current on it. If needed I can find time to test a > recent 9.x snapshot on it. Sorry for the delay. I tested with a 9.2 PRERELEASE snapshot and it shows the same behavior it shows on CURRENT. Any further tests or things I can do to help diagnose this problem? -- Guido Falsi From owner-freebsd-net@FreeBSD.ORG Fri Jul 19 01:21:13 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F1987AAD for ; Fri, 19 Jul 2013 01:21:12 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by mx1.freebsd.org (Postfix) with ESMTP id C03C25E0 for ; Fri, 19 Jul 2013 01:21:12 +0000 (UTC) Received: by mail-oa0-f41.google.com with SMTP id n10so5173714oag.14 for ; Thu, 18 Jul 2013 18:21:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mFgQ5LrlcV3BT3IcdqbITL2W/RE1n1TLrZID82HJJHY=; b=ZSOfg+JrHOLX+z09cXhPdT3KJZ7evzbdXv6whThrpullXSnM8AhHK6H58kREaoSVRp 5MOedhLyvmzEG8NL2eTaWnRkKXCF+L0a7RoSN6oSsLmm6kGLaRs9PfugPwlcOlVtZSmt 9Sbb1QOfw+R2lP0uBRZh84l3yqpEyEyzH9NwOiRnerG1AMQQOBy4VNFztnFNJyeIGmVL yse+77Ck6cMThe9Ipsj8KOY6viSMMbKImKeRmcI3vjDhd9bqW5Mqg8Z+yb57WKdwBeeZ VGKtAUZv07xCHxZth2FR5twhM05P51QV+aed1G/9F9VBL302bpZ2M0zJbuC5PbsbtyCV kbsQ== MIME-Version: 1.0 X-Received: by 10.60.102.202 with SMTP id fq10mr16144036oeb.42.1374196872293; Thu, 18 Jul 2013 18:21:12 -0700 (PDT) Received: by 10.76.13.35 with HTTP; Thu, 18 Jul 2013 18:21:12 -0700 (PDT) In-Reply-To: <06BA4BD5-BE4E-4184-AFBB-D7FD4B2597D9@your.org> References: <06BA4BD5-BE4E-4184-AFBB-D7FD4B2597D9@your.org> Date: Thu, 18 Jul 2013 21:21:12 -0400 Message-ID: Subject: Re: Duplicate Address Detection misfire? From: Zaphod Beeblebrox To: Kevin Day Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Jul 2013 01:21:13 -0000 On Sun, Jun 30, 2013 at 10:39 PM, Kevin Day wrote: > > On Jun 30, 2013, at 6:48 PM, Zaphod Beeblebrox wrote: > > > I have a FreeBSD 9.1-RELEASE vmware guest running. It is using the > > "bridged" type of networking with VMWare. It gets it's IPv4 address from > > DHCP (successfully) and then fails to initialize IPv6. The relevant > > rc.conf is: > > > > ipv6_activate_all_interfaces="YES" > > ifconfig_em0_ipv6="inet6 accept_rtadv" > > ip6addrctl_verbose="YES" > > > > The console output says: > > > > em0: DAD detected duplicate IPv6 address fe80:2::20c:29ff:fe0a:3989: NS > > in/out=2/1, NA in=0 > > em0: DAD complete for fe80:2::20c:29ff:fe0a:3989 - duplicate found > > em0: manual intervention required > > em0: possible hardware address duplication deteted, disable IPv6 > > > > And subsequently, em0's nd6 has "IFDISABLED" in it. > > > > With wireshark, I see two ICMPv6 neighbor solicitations that are > identical > > --- is this the problem? > > > > How do I fix this? > > Did you copy this VM and have both copies running at once? If so, it > assigned the same MAC address to each VM. > > VMware is suppose to detect this and ask if you "copied" or "moved" the > VM, and if you say "copied" it will randomly assign a new MAC to the VM. If > this didn't happen or if you said "moved" when you actually copied it, just > go in and delete/re-create the network interface in the VM's settings to > create a new MAC for it. > > If that's not the issue, we'd probably need more details about your > configuration. > To further diagnose, there is only one VM running. To ensure that there were no duplicates, I reassigned the MAC address in the VMWare configuration dialogue. Additionally, I tried stopping rtadvd on my router (no effect) and I tried putting the guest on a "host-only network" (basically isolated it) --- this clears the problem --- both the link-local and the static address are assigned. Frustrated, I dumped the windows interface that is bridged to the VMWare guest. When it boots, I see the following: 2461 19:24:16.376027000 Vmware_2e:46:fd Broadcast ARP 42 Gratuitous ARP for 66.96.20.42 (Request) 2462 19:24:16.388241000 :: ff02::1:ff00:42 ICMPv6 78 Neighbor Solicitation for 2001:1928:1::42 2463 19:24:16.389065000 :: ff02::1:ff00:42 ICMPv6 78 Neighbor Solicitation for 2001:1928:1::42 2464 19:24:16.444130000 :: ff02::16 ICMPv6 130 Multicast Listener Report Message v2 2465 19:24:16.444605000 :: ff02::16 ICMPv6 130 Multicast Listener Report Message v2 2466 19:24:16.594663000 :: ff02::1:ff2e:46fd ICMPv6 78 Neighbor Solicitation for fe80::250:56ff:fe2e:46fd 2467 19:24:16.595179000 :: ff02::1:ff2e:46fd ICMPv6 78 Neighbor Solicitation for fe80::250:56ff:fe2e:46fd 2753 19:24:22.274728000 Vmware_2e:46:fd Broadcast ARP 42 Who has 66.96.20.33? Tell 66.96.20.42 2754 19:24:22.274902000 Intel_bc:6f:87 Vmware_2e:46:fd ARP 60 66.96.20.33 is at 00:0e:0c:bc:6f:87 ... and then it goes on to chatter ipv4-wise as expected. Note that there are two of each packet. Is that normal? The ethernet source of all these packets is my vmware guest (save the who-has reply that I copied in). From owner-freebsd-net@FreeBSD.ORG Fri Jul 19 01:50:15 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 823A52F1 for ; Fri, 19 Jul 2013 01:50:15 +0000 (UTC) (envelope-from bsd-lists@1command.com) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) by mx1.freebsd.org (Postfix) with ESMTP id 0BBB56E8 for ; Fri, 19 Jul 2013 01:50:14 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id r6J1oUQF002893 for ; Thu, 18 Jul 2013 18:50:36 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id r6J1oPS4002890; Thu, 18 Jul 2013 18:50:25 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Thu, 18 Jul 2013 18:50:25 -0700 (PDT) Message-ID: <87f5f1b42a5000af74a50ed20e46318e.authenticated@ultimatedns.net> In-Reply-To: <51E85E85.1040601@madpilot.net> References: <51DC726D.6040601@madpilot.net> <20130710070431.GE2753@michelle.cdnetworks.com> <51DD9E15.7070609@madpilot.net> <51E85E85.1040601@madpilot.net> Date: Thu, 18 Jul 2013 18:50:25 -0700 (PDT) Subject: Re: re0 not working at boot on -CURRENT From: "Chris H" To: freebsd-net@freebsd.org User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Jul 2013 01:50:15 -0000 > On 07/10/13 19:47, Guido Falsi wrote: >> On 07/10/13 09:04, Yonghyeon PYUN wrote: >>> On Tue, Jul 09, 2013 at 10:28:29PM +0200, Guido Falsi wrote: >>>> Hi, >>>> >>>> I have a PC with an integrate re ethernet interface, pciconf identifies >>>> it like this: >>>> >>>> re0@pci0:3:0:0: class=0x020000 card=0x11c01734 chip=0x816810ec rev=0x07 >>>> hdr=0x00 >>>> >>>> I'm running FreeBSD current r252261. >>>> >>>> As stated in the subject after boot the interface does not work >>>> correctly. >>>> >>>> Using tcpdump on another host I noticed that packets (ICMP echo requests >>>> for example) do get sent, and replies generated by the other host, but >>>> the kernel does not seem to see them. Except that every now and then >>>> some packet does get to the system. >>>> >>>> I'm seeing packet 7, 27, 47, 66, 86, 106, 125, 144, 164, 183 and so on >>>> from a ping which has been running for some time. Just about one every >>>> twenty. Some pattern is showing up. >>>> >>>> this is the output of ifconfig re0 after boot: >>>> >>>> re0: flags=8843 metric 0 mtu >>>> 1500 >>>> >>>> options=8209b >>>> >>>> ether 00:19:99:f8:d3:0b >>>> inet 172.24.42.13 netmask 0xffffff00 broadcast 172.24.42.255 >>>> inet6 fe80::219:99ff:fef8:d30b%re0 prefixlen 64 scopeid 0x2 >>>> nd6 options=29 >>>> media: Ethernet autoselect (100baseTX ) >>>> status: active >>>> >>>> If I just touch any interface flag with ifconfig, anyone, tso, -txcsum >>>> -rxcsum, it starts working flawlessly. It keeps working also if I >>>> perform the opposite operation with ifconfig afterwards, so it is not >>>> the flag itself fixing it. >>>> >>>> This is an ifconfig after performing this exercise(it's the same, since >>>> I disabled txcsum and reactivated it in this instance): >>>> >>>> re0: flags=8843 metric 0 mtu >>>> 1500 >>>> >>>> options=8209b >>>> >>>> ether 00:19:99:f8:d3:0b >>>> inet 172.24.42.13 netmask 0xffffff00 broadcast 172.24.42.255 >>>> inet6 fe80::219:99ff:fef8:d30b%re0 prefixlen 64 scopeid 0x2 >>>> nd6 options=29 >>>> media: Ethernet autoselect (100baseTX ) >>>> status: active >>>> >>>> I don't know much about FreeBSD network drivers so i can't make theories >>>> about this. I hope someone has an idea what the problem could be. >>>> >>>> I'm available for any further information needed, test, experiment and >>>> so on. >>> >>> Could you show me dmesg output(re(4) and rgephy(4) only)? >> >> re0: port >> 0xd000-0xd0ff mem 0xf2104000-0xf2104fff,0xf2100000-0xf2103fff irq 17 at >> device 0.0 on pci3 >> re0: Using 1 MSI-X message >> re0: turning off MSI enable bit. >> re0: Chip rev. 0x2c800000 >> re0: MAC rev. 0x00000000 >> re0: Ethernet address: 00:19:99:f8:d3:0b >> miibus0: on re0 >> rgephy0: PHY 1 on miibus0 >> rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, >> 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, >> 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, >> 1000baseT-FDX-flow-master, auto, auto-flow >> >> Also, I'm loading this as a module, but, for as much as I know, this >> should not make any difference. >> >> >>> Did it ever work or you see the issue only on CURRENT? >> >> Never worked on this machine (I own it since the last days of February). >> >> I only installed current on it. If needed I can find time to test a >> recent 9.x snapshot on it. > > Sorry for the delay. > > I tested with a 9.2 PRERELEASE snapshot and it shows the same behavior > it shows on CURRENT. > > Any further tests or things I can do to help diagnose this problem? > > -- > Guido Falsi Greetings, I may be just groping here, but I notice in your ifconfig(8) output: >>>> nd6 options=29 ________________________________________^^^^^^^^^^ While you may have explicitly disabled it; my output (also re0) reads: nd6 options=3 Just saying, cause I'm not experiencing your issue(s), and mine is also an onboard NIC. --chris > _______________________________________________ > 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 19 01:58:09 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5AF194C5 for ; Fri, 19 Jul 2013 01:58:09 +0000 (UTC) (envelope-from bsd-lists@1command.com) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) by mx1.freebsd.org (Postfix) with ESMTP id 230FF788 for ; Fri, 19 Jul 2013 01:58:08 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id r6J1wVDI003479 for ; Thu, 18 Jul 2013 18:58:37 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id r6J1wQcT003476; Thu, 18 Jul 2013 18:58:26 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Thu, 18 Jul 2013 18:58:26 -0700 (PDT) Message-ID: In-Reply-To: <87f5f1b42a5000af74a50ed20e46318e.authenticated@ultimatedns.net> References: <51DC726D.6040601@madpilot.net> <20130710070431.GE2753@michelle.cdnetworks.com> <51DD9E15.7070609@madpilot.net> <51E85E85.1040601@madpilot.net> <87f5f1b42a5000af74a50ed20e46318e.authenticated@ultimatedns.net> Date: Thu, 18 Jul 2013 18:58:26 -0700 (PDT) Subject: Re: re0 not working at boot on -CURRENT From: "Chris H" To: freebsd-net@freebsd.org User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Jul 2013 01:58:09 -0000 >> On 07/10/13 19:47, Guido Falsi wrote: >>> On 07/10/13 09:04, Yonghyeon PYUN wrote: >>>> On Tue, Jul 09, 2013 at 10:28:29PM +0200, Guido Falsi wrote: >>>>> Hi, >>>>> >>>>> I have a PC with an integrate re ethernet interface, pciconf identifies >>>>> it like this: >>>>> >>>>> re0@pci0:3:0:0: class=0x020000 card=0x11c01734 chip=0x816810ec rev=0x07 >>>>> hdr=0x00 >>>>> >>>>> I'm running FreeBSD current r252261. >>>>> >>>>> As stated in the subject after boot the interface does not work >>>>> correctly. >>>>> >>>>> Using tcpdump on another host I noticed that packets (ICMP echo requests >>>>> for example) do get sent, and replies generated by the other host, but >>>>> the kernel does not seem to see them. Except that every now and then >>>>> some packet does get to the system. >>>>> >>>>> I'm seeing packet 7, 27, 47, 66, 86, 106, 125, 144, 164, 183 and so on >>>>> from a ping which has been running for some time. Just about one every >>>>> twenty. Some pattern is showing up. >>>>> >>>>> this is the output of ifconfig re0 after boot: >>>>> >>>>> re0: flags=8843 metric 0 mtu >>>>> 1500 >>>>> >>>>> options=8209b >>>>> >>>>> ether 00:19:99:f8:d3:0b >>>>> inet 172.24.42.13 netmask 0xffffff00 broadcast 172.24.42.255 >>>>> inet6 fe80::219:99ff:fef8:d30b%re0 prefixlen 64 scopeid 0x2 >>>>> nd6 options=29 >>>>> media: Ethernet autoselect (100baseTX ) >>>>> status: active >>>>> >>>>> If I just touch any interface flag with ifconfig, anyone, tso, -txcsum >>>>> -rxcsum, it starts working flawlessly. It keeps working also if I >>>>> perform the opposite operation with ifconfig afterwards, so it is not >>>>> the flag itself fixing it. >>>>> >>>>> This is an ifconfig after performing this exercise(it's the same, since >>>>> I disabled txcsum and reactivated it in this instance): >>>>> >>>>> re0: flags=8843 metric 0 mtu >>>>> 1500 >>>>> >>>>> options=8209b >>>>> >>>>> ether 00:19:99:f8:d3:0b >>>>> inet 172.24.42.13 netmask 0xffffff00 broadcast 172.24.42.255 >>>>> inet6 fe80::219:99ff:fef8:d30b%re0 prefixlen 64 scopeid 0x2 >>>>> nd6 options=29 >>>>> media: Ethernet autoselect (100baseTX ) >>>>> status: active >>>>> >>>>> I don't know much about FreeBSD network drivers so i can't make theories >>>>> about this. I hope someone has an idea what the problem could be. >>>>> >>>>> I'm available for any further information needed, test, experiment and >>>>> so on. >>>> >>>> Could you show me dmesg output(re(4) and rgephy(4) only)? >>> >>> re0: port >>> 0xd000-0xd0ff mem 0xf2104000-0xf2104fff,0xf2100000-0xf2103fff irq 17 at >>> device 0.0 on pci3 >>> re0: Using 1 MSI-X message >>> re0: turning off MSI enable bit. >>> re0: Chip rev. 0x2c800000 >>> re0: MAC rev. 0x00000000 >>> re0: Ethernet address: 00:19:99:f8:d3:0b >>> miibus0: on re0 >>> rgephy0: PHY 1 on miibus0 >>> rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, >>> 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, >>> 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, >>> 1000baseT-FDX-flow-master, auto, auto-flow >>> >>> Also, I'm loading this as a module, but, for as much as I know, this >>> should not make any difference. >>> >>> >>>> Did it ever work or you see the issue only on CURRENT? >>> >>> Never worked on this machine (I own it since the last days of February). >>> >>> I only installed current on it. If needed I can find time to test a >>> recent 9.x snapshot on it. >> >> Sorry for the delay. >> >> I tested with a 9.2 PRERELEASE snapshot and it shows the same behavior >> it shows on CURRENT. >> >> Any further tests or things I can do to help diagnose this problem? >> >> -- >> Guido Falsi > Greetings, > I may be just groping here, but I notice in your ifconfig(8) output: >>>>> nd6 options=29 > ________________________________________^^^^^^^^^^ > While you may have explicitly disabled it; my output (also re0) reads: > nd6 options=3 > > Just saying, cause I'm not experiencing your issue(s), and mine is also an onboard > NIC. > > --chris P.S. There were also recent changes to rc(8) regarding the syntax of ifconfig. > >> _______________________________________________ >> 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 19 02:46:38 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3C254CE1 for ; Fri, 19 Jul 2013 02:46:38 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id A71D694E for ; Fri, 19 Jul 2013 02:46:37 +0000 (UTC) Received: from alph.d.allbsd.org (p2049-ipbf1102funabasi.chiba.ocn.ne.jp [122.26.101.49]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r6J2kFUw098154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 11:46:25 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.5/8.14.5) with ESMTP id r6J2kDqf049648; Fri, 19 Jul 2013 11:46:15 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 19 Jul 2013 11:13:40 +0900 (JST) Message-Id: <20130719.111340.2074663570989807399.hrs@allbsd.org> To: therion@ninth-art.de Subject: Re: IPv6 NDP, static subnet entries From: Hiroki Sato In-Reply-To: <1374064573.525.2.camel@atwork> References: <1374064573.525.2.camel@atwork> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Jul_19_11_13_40_2013_183)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Fri, 19 Jul 2013 11:46:26 +0900 (JST) X-Spam-Status: No, score=-89.3 required=13.0 tests=CONTENT_TYPE_PRESENT, DIRECTOCNDYN,DYN_PBL,RCVD_IN_PBL,RCVD_IN_RP_RNBL,SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Jul 2013 02:46:38 -0000 ----Security_Multipart(Fri_Jul_19_11_13_40_2013_183)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Georg Bege wrote in <1374064573.525.2.camel@atwork>: th> Hello FreeBSD users th> th> Im in need of proxying an NDP entry, th> due my bad provider using IPv6 bridging. th> My entire subnet is not routed correctly, however I managed to get it th> working with ndp -s proxy - sadly this doesnt work th> for an whole subnet but for a single IP. th> th> I need exacly this for an whole subnet, is it possible? More specifics about your network and what ISP provided are needed to answer to this... -- Hiroki ----Security_Multipart(Fri_Jul_19_11_13_40_2013_183)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlHooNQACgkQTyzT2CeTzy3phACgxKZxUbsns8A+diG1HFVGhYwJ HpAAn3DFOz+77jMQgrJn83kt35RKHXVo =0GYa -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Jul_19_11_13_40_2013_183)---- From owner-freebsd-net@FreeBSD.ORG Fri Jul 19 06:26:36 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D27CE36A for ; Fri, 19 Jul 2013 06:26:36 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from winston.madpilot.net (winston.madpilot.net [78.47.75.155]) by mx1.freebsd.org (Postfix) with ESMTP id 2F844275 for ; Fri, 19 Jul 2013 06:26:35 +0000 (UTC) Received: from winston.madpilot.net (localhost [127.0.0.1]) by winston.madpilot.net (Postfix) with ESMTP id 3bxMgG2mJ0zFTNf for ; Fri, 19 Jul 2013 08:26:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at madpilot.net Received: from winston.madpilot.net ([127.0.0.1]) by winston.madpilot.net (winston.madpilot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neY57FrfAWIS for ; Fri, 19 Jul 2013 08:26:32 +0200 (CEST) Received: from marvin.madpilot.net (micro.madpilot.net [88.149.173.206]) by winston.madpilot.net (Postfix) with ESMTPSA for ; Fri, 19 Jul 2013 08:26:32 +0200 (CEST) Message-ID: <51E8DC18.8030109@madpilot.net> Date: Fri, 19 Jul 2013 08:26:32 +0200 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130627 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: re0 not working at boot on -CURRENT References: <51DC726D.6040601@madpilot.net> <20130710070431.GE2753@michelle.cdnetworks.com> <51DD9E15.7070609@madpilot.net> <51E85E85.1040601@madpilot.net> <87f5f1b42a5000af74a50ed20e46318e.authenticated@ultimatedns.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Jul 2013 06:26:36 -0000 On 07/19/13 03:58, Chris H wrote: >>> On 07/10/13 19:47, Guido Falsi wrote: >>>> On 07/10/13 09:04, Yonghyeon PYUN wrote: >>>>> On Tue, Jul 09, 2013 at 10:28:29PM +0200, Guido Falsi wrote: >>>>>> Hi, >>>>>> >>>>>> I have a PC with an integrate re ethernet interface, pciconf identifies >>>>>> it like this: >>>>>> >>>>>> re0@pci0:3:0:0: class=0x020000 card=0x11c01734 chip=0x816810ec rev=0x07 >>>>>> hdr=0x00 >>>>>> >>>>>> I'm running FreeBSD current r252261. >>>>>> >>>>>> As stated in the subject after boot the interface does not work >>>>>> correctly. >>>>>> >>>>>> Using tcpdump on another host I noticed that packets (ICMP echo requests >>>>>> for example) do get sent, and replies generated by the other host, but >>>>>> the kernel does not seem to see them. Except that every now and then >>>>>> some packet does get to the system. >>>>>> >>>>>> I'm seeing packet 7, 27, 47, 66, 86, 106, 125, 144, 164, 183 and so on >>>>>> from a ping which has been running for some time. Just about one every >>>>>> twenty. Some pattern is showing up. >>>>>> >>>>>> this is the output of ifconfig re0 after boot: >>>>>> >>>>>> re0: flags=8843 metric 0 mtu >>>>>> 1500 >>>>>> >>>>>> options=8209b >>>>>> >>>>>> ether 00:19:99:f8:d3:0b >>>>>> inet 172.24.42.13 netmask 0xffffff00 broadcast 172.24.42.255 >>>>>> inet6 fe80::219:99ff:fef8:d30b%re0 prefixlen 64 scopeid 0x2 >>>>>> nd6 options=29 >>>>>> media: Ethernet autoselect (100baseTX ) >>>>>> status: active >>>>>> >>>>>> If I just touch any interface flag with ifconfig, anyone, tso, -txcsum >>>>>> -rxcsum, it starts working flawlessly. It keeps working also if I >>>>>> perform the opposite operation with ifconfig afterwards, so it is not >>>>>> the flag itself fixing it. >>>>>> >>>>>> This is an ifconfig after performing this exercise(it's the same, since >>>>>> I disabled txcsum and reactivated it in this instance): >>>>>> >>>>>> re0: flags=8843 metric 0 mtu >>>>>> 1500 >>>>>> >>>>>> options=8209b >>>>>> >>>>>> ether 00:19:99:f8:d3:0b >>>>>> inet 172.24.42.13 netmask 0xffffff00 broadcast 172.24.42.255 >>>>>> inet6 fe80::219:99ff:fef8:d30b%re0 prefixlen 64 scopeid 0x2 >>>>>> nd6 options=29 >>>>>> media: Ethernet autoselect (100baseTX ) >>>>>> status: active >>>>>> >>>>>> I don't know much about FreeBSD network drivers so i can't make theories >>>>>> about this. I hope someone has an idea what the problem could be. >>>>>> >>>>>> I'm available for any further information needed, test, experiment and >>>>>> so on. >>>>> >>>>> Could you show me dmesg output(re(4) and rgephy(4) only)? >>>> >>>> re0: port >>>> 0xd000-0xd0ff mem 0xf2104000-0xf2104fff,0xf2100000-0xf2103fff irq 17 at >>>> device 0.0 on pci3 >>>> re0: Using 1 MSI-X message >>>> re0: turning off MSI enable bit. >>>> re0: Chip rev. 0x2c800000 >>>> re0: MAC rev. 0x00000000 >>>> re0: Ethernet address: 00:19:99:f8:d3:0b >>>> miibus0: on re0 >>>> rgephy0: PHY 1 on miibus0 >>>> rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, >>>> 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, >>>> 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, >>>> 1000baseT-FDX-flow-master, auto, auto-flow >>>> >>>> Also, I'm loading this as a module, but, for as much as I know, this >>>> should not make any difference. >>>> >>>> >>>>> Did it ever work or you see the issue only on CURRENT? >>>> >>>> Never worked on this machine (I own it since the last days of February). >>>> >>>> I only installed current on it. If needed I can find time to test a >>>> recent 9.x snapshot on it. >>> >>> Sorry for the delay. >>> >>> I tested with a 9.2 PRERELEASE snapshot and it shows the same behavior >>> it shows on CURRENT. >>> >>> Any further tests or things I can do to help diagnose this problem? >>> >>> -- >>> Guido Falsi >> Greetings, >> I may be just groping here, but I notice in your ifconfig(8) output: >>>>>> nd6 options=29 >> ________________________________________^^^^^^^^^^ >> While you may have explicitly disabled it; my output (also re0) reads: >> nd6 options=3 >> >> Just saying, cause I'm not experiencing your issue(s), and mine is also an onboard >> NIC. I noticed that too, but it's only on the IPv6 interface, I'm using only IPv4 at this time. Also, it works fine after the "ifconfig re0 " (flag being any from tso, -rxcsum, -txcsum etc) with that IFDISABLED active. I'm seeing that IFDISABLED on all the IPV6 options of all the interfaces of the machines I manage. >> >> --chris > P.S. There were also recent changes to rc(8) regarding the syntax of ifconfig. >> Uhm, I'll check, I can't test a newer -current right now, but I will do in a few weeks at most. -- Guido Falsi From owner-freebsd-net@FreeBSD.ORG Fri Jul 19 06:58:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BCC85B3A for ; Fri, 19 Jul 2013 06:58:33 +0000 (UTC) (envelope-from fernando@gont.com.ar) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by mx1.freebsd.org (Postfix) with ESMTP id 88FF338A for ; Fri, 19 Jul 2013 06:58:33 +0000 (UTC) Received: from [2001:5c0:1400:a::7a5] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V04e5-0004Tw-38; Fri, 19 Jul 2013 08:58:29 +0200 Message-ID: <51E8E393.50504@gont.com.ar> Date: Fri, 19 Jul 2013 08:58:27 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Matt Miller Subject: Re: TCP Loopback Connections with the Same Src/Dest Port References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Jul 2013 06:58:33 -0000 Hi, Matt, Please heck this IETF Internet-Draft: Some comments: On 07/17/2013 01:08 PM, Matt Miller wrote: > > Some questions we had: > > - Has anyone else ever seen these same src/dest address/port TCP > connections created? Does anyone know of a legitimate reason why they > should be allowed? Could be used for TCP-based IPC. > - If there are no known use cases for this type of connection, does > anyone have more context/insight on the design here: should this type > of inpcb creation be prevented in the kernel or is it the > application's responsibility to ensure it never creates this type of > socket? It should be allowed -- although some systems have been known to fail to handle this scenarios gracefully. > For those interested, more details of the issue seen follow. The > connection seems to get stuck in swi_net sending and receiving pure > FIN/ACKs to itself: > > #12 0xffffffff804372ce in ip_output (m=0xffffff0003ccf300, > opt=, ro=0xffffff8020c2b6a0, flags=0, imo=0x0, > inp=0xffffff0019933968) at ../../../../sys/netinet/ip_output.c > #13 0xffffffff804423dc in tcp_output (tp=0xffffff0019de2370) at > ../../../../sys/netinet/tcp_output.c > #14 0xffffffff8043ef5d in tcp_do_segment (m=0xffffff0019af1200, > th=0x100200, so=0xffffff011ac59570, tp=0xffffff0019de2370, > drop_hdrlen=52, tlen=0, iptos=0 '\000', ti_locked=3) at > ../../../../sys/netinet/tcp_input.c > #15 0xffffffff80440311 in tcp_input (m=0xffffff0019af1200, > off0=) at ../../../../sys/netinet/tcp_input.c > #16 0xffffffff8043530b in ip_input (m=0xffffff0019af1200) at > ../../../../sys/netinet/ip_input.c > #17 0xffffffff8040889f in netisr_process_workstream_proto > (proto=, nwsp=) at > ../../../../sys/net/netisr.c > #18 swi_net (arg=0xffffffff80f59800) at ../../../../sys/net/netisr.c > > swi_net() just continues in this loop, ad nauseam: [...] This results in a packet war, right? (one segment sent after another, with no delays in between). > I've noticed that we don't yet have this patch in our code: > > http://svnweb.freebsd.org/base?view=revision&revision=239672 > > Which seems like it could be relevant here to the general case of both > ends of the connection entering FIN_WAIT_1 at the same time and > sending FIN/ACKs repeatedly (though our connections are a bizarre case > of this where both ends of the connection are actually the same > connection). Last time I checked, FreeBSD was handlind this case properly... so this is probably the result of the patch you're referring to. Thanks! Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From owner-freebsd-net@FreeBSD.ORG Fri Jul 19 09:29:50 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AE61144A; Fri, 19 Jul 2013 09:29:50 +0000 (UTC) (envelope-from Olivier.Nicole@cs.ait.ac.th) Received: from mail.cs.ait.ac.th (mail.cs.ait.ac.th [192.41.170.16]) by mx1.freebsd.org (Postfix) with ESMTP id 62944C2A; Fri, 19 Jul 2013 09:29:50 +0000 (UTC) Received: from mail.cs.ait.ac.th (localhost [127.0.0.1]) by mail.cs.ait.ac.th (Postfix) with ESMTP id 0E76EFEBD7; Fri, 19 Jul 2013 16:29:43 +0700 (ICT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.ait.ac.th; h= content-type:content-type:mime-version:message-id:date:date:from :from:subject:subject:received:received:received; s=selector1; t=1374226182; x=1376040583; bh=/2ENGVAFFUvJRqBL1Zh8UPag33FYhV8q tbcmPHelGno=; b=PcOUdm52M156ZGku8YNUrsAP0RlQ4YfCt3ZoaR4q1RjKIxo2 +7id4zbWspBK8yJmYjybA3Cdi7lNJojYf4H71dN/K68b4v/ZK3K3aFPIXKVuhiAk n03h3u+WbocJdqvkKaoZRtu09km+X+FxfG531+/8bbD3smDXCtiK2NroVb0= X-Virus-Scanned: amavisd-new at cs.ait.ac.th Received: from mail.cs.ait.ac.th ([127.0.0.1]) by mail.cs.ait.ac.th (mail.cs.ait.ac.th [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JtvinY-FYQcz; Fri, 19 Jul 2013 16:29:42 +0700 (ICT) Received: from banyan.cs.ait.ac.th (banyan.cs.ait.ac.th [192.41.170.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.ait.ac.th (Postfix) with ESMTPS id C106BFEBCF; Fri, 19 Jul 2013 16:29:42 +0700 (ICT) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.14.5/8.14.5/Submit) id r6J9TgiS009335; Fri, 19 Jul 2013 16:29:42 +0700 (ICT) (envelope-from on@banyan.cs.ait.ac.th) To: questions@freebsd.org, freebsd-net@freebsd.org Subject: Same MAC address in 2 different VLANs From: Olivier Nicole Date: Fri, 19 Jul 2013 16:29:42 +0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Jul 2013 09:29:50 -0000 Hello, Could any one comment about the use of the same MAC address in 2 separate VLANs? All my machines are connected to 2 VLANs (one public and one private) with no routing in between the VLANs. I used to run a FLEX license manager to a physical machine. When I virtualized that service, I had to use the MAC address of that physical machine for the virtual machine (FLEX is linked to the MAc address and I coul dnot issue new license as licensed the pproduct is not supported anymore). The virtual NIC that has the old MAC address is connected to the public VLAN. Now I want to reuse the physical machine as a VMware server. Dell nor VMware offer a solution to change the MAC address (like ifconfig em0 link xx:xx:xx:xx:xx:xx would do). So I plan to connect the NIC with the incriminated MAC to the private VLAN. Most (if not all) my servers are FreeBSD. Most will access the virtual machine running FLEX and may access the VMware server also. The servers are not VLAN aware. Will this be an issue? Best regars, Olivier -- From owner-freebsd-net@FreeBSD.ORG Fri Jul 19 09:32:39 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3BE7D5E9; Fri, 19 Jul 2013 09:32:39 +0000 (UTC) (envelope-from therion@ninth-art.de) Received: from mail.unix.io (mail.unix.io [IPv6:2001:41d0:2:83a5::2]) by mx1.freebsd.org (Postfix) with ESMTP id F2587C5D; Fri, 19 Jul 2013 09:32:38 +0000 (UTC) Received: from mail.unix.io (localhost [127.0.0.1]) by mail.unix.io (Postfix) with ESMTP id 9865725C6; Fri, 19 Jul 2013 11:32:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=ninth-art.de; h=subject :from:reply-to:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s=mail2013; bh=Zp3v19q11w3z1jyXp7I9FMUMFx8=; b=nY9r4blLnkn5VrckclQG1NxcuyT0 dpSDXgbxBAyrTR+kWD4yseWjRUPVX5cb2dFSnjaM1kWdMmLYKimA1lLQSbHW2WyA acm5u49TNTBJhWpyd4h2q4xhIipfbbxPpDYtVcZjhEe6nmjapXZ+vjtIsHyVqgEA Ao6gaA+w4F6kQwQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=ninth-art.de; h=subject:from :reply-to:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; q=dns; s= mail2013; b=TO7KfOySc69pZ1/VVsg/EVsZ0Cn12bGVBBN//+3p4V2xthtPqNsz 8bABu/0fiQ+UMhqoxWJSRWFzoweIKKKr29Im3N3RLvleXr9AaqgPpf0tlKwCbLdA FmKBm7FV/TIpMdWjsoYRk1TMLl5QH8DsbzL1TbAe64+9u9lVK3qCgTc= Received: from [192.168.2.4] (p4FE4F42C.dip0.t-ipconnect.de [79.228.244.44]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unix.io (Postfix) with ESMTPSA id 6C1CF25C5; Fri, 19 Jul 2013 11:32:35 +0200 (CEST) Subject: Re: IPv6 NDP, static subnet entries From: Georg Bege To: Hiroki Sato In-Reply-To: <20130719.111340.2074663570989807399.hrs@allbsd.org> References: <1374064573.525.2.camel@atwork> <20130719.111340.2074663570989807399.hrs@allbsd.org> Content-Type: text/plain; charset="UTF-8" Date: Fri, 19 Jul 2013 11:33:02 +0200 Message-ID: <1374226382.2820.1.camel@atwork> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: therion@ninth-art.de List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 09:32:39 -0000 Hello Hiroki Well I've got the subnet 2001:41d0:2:83a5::/64 and would like to route a portion of this - let's say 2001:41d0:2:83a5:100::/124 via an gif interface. The ISP is OVH, I heard it's known for broken setups like bridging. What kind of other information would you need? Am Freitag, den 19.07.2013, 11:13 +0900 schrieb Hiroki Sato: > Georg Bege wrote > in <1374064573.525.2.camel@atwork>: > > th> Hello FreeBSD users > th> > th> Im in need of proxying an NDP entry, > th> due my bad provider using IPv6 bridging. > th> My entire subnet is not routed correctly, however I managed to get it > th> working with ndp -s proxy - sadly this doesnt work > th> for an whole subnet but for a single IP. > th> > th> I need exacly this for an whole subnet, is it possible? > > More specifics about your network and what ISP provided are needed to > answer to this... > > -- Hiroki -- Georg Bege From owner-freebsd-net@FreeBSD.ORG Fri Jul 19 10:02:28 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DAD753E0; Fri, 19 Jul 2013 10:02:28 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 4FDF2DE4; Fri, 19 Jul 2013 10:02:28 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id z11so3838492wgg.22 for ; Fri, 19 Jul 2013 03:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8ybb0axaNvUFBE3uYcyGFtFd0LXXMpCGHQl4gmsTKPU=; b=JuBG9LNHoIE8D1wWPPKvrRIT6bgtXAgvKUuP9BpSfkCHciYHdfxftbVmdPy/XufBjO uMl2ql0acE8cEQSJ2j+393rEypMEuXLGVoLxueJ14SYnQAzuzmqsl6ukD6EmKzA5oeYk qzOzCUyNhwP9vtJjyiB4fP6tvyw7EQlPMJKDPr/hYPXSIvCiStV+EtZIUUmgDduSDPoA 9b7EhY+VbZa/r4Us4wiSzzZXeWCtEItUHLp17rtsQVLN85NkeqVQOLx7GA3XZqQztjd7 Ab4kXYpKT4Wm0YP/kQsHUM7hH9I9E5z1xNkFWKbgqg3NJUbFz/lT/GMpye17d857glqh g+/w== MIME-Version: 1.0 X-Received: by 10.180.11.146 with SMTP id q18mr10906537wib.50.1374228147406; Fri, 19 Jul 2013 03:02:27 -0700 (PDT) Received: by 10.216.68.137 with HTTP; Fri, 19 Jul 2013 03:02:27 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Jul 2013 11:02:27 +0100 Message-ID: Subject: Re: Same MAC address in 2 different VLANs From: krad To: Olivier Nicole Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org, questions@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Jul 2013 10:02:28 -0000 I think you maybe ok. Ive just looked at my esx config and the esx management interfaces use their own generated macs, not the physical interfaces ones. All the vms obviously use generated macs as well. However I only looked over it at a superficial level. Have you considered using a tap or spare phyical interface on your flex box and not linking it to the network? On 19 July 2013 10:29, Olivier Nicole wrote: > Hello, > > Could any one comment about the use of the same MAC address in 2 > separate VLANs? > > All my machines are connected to 2 VLANs (one public and one private) > with no routing in between the VLANs. > > I used to run a FLEX license manager to a physical machine. When I > virtualized that service, I had to use the MAC address of that physical > machine for the virtual machine (FLEX is linked to the MAc address and I > coul dnot issue new license as licensed the pproduct is not supported > anymore). The virtual NIC that has the old MAC address is connected to > the public VLAN. > > Now I want to reuse the physical machine as a VMware server. Dell nor > VMware offer a solution to change the MAC address (like > ifconfig em0 link xx:xx:xx:xx:xx:xx would do). So I plan to connect the > NIC with the incriminated MAC to the private VLAN. > > Most (if not all) my servers are FreeBSD. Most will access the virtual > machine running FLEX and may access the VMware server also. The servers > are not VLAN aware. > > Will this be an issue? > > Best regars, > > Olivier > > -- > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > freebsd-questions-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Jul 19 10:39:22 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6A4251B8; Fri, 19 Jul 2013 10:39:22 +0000 (UTC) (envelope-from joost@jodocus.org) Received: from fep23.mx.upcmail.net (fep23.mx.upcmail.net [62.179.121.43]) by mx1.freebsd.org (Postfix) with ESMTP id 85F8CFA0; Fri, 19 Jul 2013 10:39:19 +0000 (UTC) Received: from edge03.upcmail.net ([192.168.13.238]) by viefep23-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20130719103912.WXC15242.viefep23-int.chello.at@edge03.upcmail.net>; Fri, 19 Jul 2013 12:39:12 +0200 Received: from vione.jodocus.org ([212.187.72.205]) by edge03.upcmail.net with edge id 2Af61m00X4RktKG03Af9eH; Fri, 19 Jul 2013 12:39:12 +0200 X-SourceIP: 212.187.72.205 Received: from jodocus.org (localhost [127.0.0.1]) by vione.jodocus.org (Postfix) with ESMTP id E612CA47; Fri, 19 Jul 2013 12:39:05 +0200 (CEST) Received: from 212.203.12.51 (SquirrelMail authenticated user joost) by jodocus.org with HTTP; Fri, 19 Jul 2013 12:39:06 +0200 Message-ID: In-Reply-To: References: Date: Fri, 19 Jul 2013 12:39:06 +0200 Subject: Re: Same MAC address in 2 different VLANs From: joost@jodocus.org To: questions@freebsd.org, freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Olivier Nicole X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Jul 2013 10:39:22 -0000 > Hello, > > Could any one comment about the use of the same MAC address in 2 > separate VLANs? > [...] > > Will this be an issue? > You might run into problems if the two (virtual) systems are attached to a different port on your switch. Some switches don't take the vlan into account when learning on which port a mac address exists. These switches will see the mac address jumping between ports all the time. Joost. From owner-freebsd-net@FreeBSD.ORG Fri Jul 19 12:39:46 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 937A44D8 for ; Fri, 19 Jul 2013 12:39:46 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 0FF057E9 for ; Fri, 19 Jul 2013 12:39:45 +0000 (UTC) Received: from alph.d.allbsd.org (p2049-ipbf1102funabasi.chiba.ocn.ne.jp [122.26.101.49]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r6JCdSql061049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 21:39:38 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.5/8.14.5) with ESMTP id r6JCdQ7P064981; Fri, 19 Jul 2013 21:39:28 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 19 Jul 2013 21:13:54 +0900 (JST) Message-Id: <20130719.211354.536896668939641321.hrs@allbsd.org> To: therion@ninth-art.de Subject: Re: IPv6 NDP, static subnet entries From: Hiroki Sato In-Reply-To: <1374226382.2820.1.camel@atwork> References: <1374064573.525.2.camel@atwork> <20130719.111340.2074663570989807399.hrs@allbsd.org> <1374226382.2820.1.camel@atwork> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Jul_19_21_13_54_2013_878)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Fri, 19 Jul 2013 21:39:38 +0900 (JST) X-Spam-Status: No, score=-89.3 required=13.0 tests=CONTENT_TYPE_PRESENT, DIRECTOCNDYN,DYN_PBL,RCVD_IN_PBL,RCVD_IN_RP_RNBL,SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Jul 2013 12:39:46 -0000 ----Security_Multipart(Fri_Jul_19_21_13_54_2013_878)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Georg Bege wrote in <1374226382.2820.1.camel@atwork>: th> Hello Hiroki th> th> Well I've got the subnet 2001:41d0:2:83a5::/64 and would like to route a th> portion of this - let's say 2001:41d0:2:83a5:100::/124 via an gif th> interface. th> The ISP is OVH, I heard it's known for broken setups like bridging. th> What kind of other information would you need? Routing to a subnet of 2001:41d0:2:83a5::/64 needs to add an routing entry to the router which handles incoming packets in 2001:41d0:2:83a5::/64. As far as I can tell your router on OVH's side uses the address 2001:41d0:2:83ff:ff:ff:ff:ff and this router is not under your control---is it true? If so, it is difficult to create a subnet. -- Hiroki ----Security_Multipart(Fri_Jul_19_21_13_54_2013_878)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlHpLYIACgkQTyzT2CeTzy0e8QCgjMEdSI4gv81rNelFENVm0ugG EKMAoINjtgRoIG1XtiK33+Olk4m2eB0n =GRdA -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Jul_19_21_13_54_2013_878)---- From owner-freebsd-net@FreeBSD.ORG Fri Jul 19 15:30:02 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 192A9AC for ; Fri, 19 Jul 2013 15:30:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 0BB36FF6 for ; Fri, 19 Jul 2013 15:30:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6JFU1Oh046936 for ; Fri, 19 Jul 2013 15:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6JFU1uH046935; Fri, 19 Jul 2013 15:30:01 GMT (envelope-from gnats) Date: Fri, 19 Jul 2013 15:30:01 GMT Message-Id: <201307191530.r6JFU1uH046935@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: John Baldwin Subject: Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragmented packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: John Baldwin List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 15:30:02 -0000 The following reply was made to PR kern/180430; it has been noted by GNATS. From: John Baldwin To: bug-followup@freebsd.org, menyy@mellanox.com Cc: Subject: Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragmented packets Date: Fri, 19 Jul 2013 11:13:44 -0400 Oops, my previous reply didn't make it to the PR itself. Is the problem that the hardware checksum overwrites arbitrary data in the packet (at the location where the UDP header would be)? Also, I've looked at other drivers, and they all look at the CSUM_* flags to determine the right settings. IP fragments will not have CSUM_UDP or CSUM_TCP set, so I think the more correct fix is this: Index: en_tx.c =================================================================== --- en_tx.c (revision 253470) +++ en_tx.c (working copy) @@ -780,8 +780,12 @@ retry: tx_desc->ctrl.srcrb_flags = cpu_to_be32(MLX4_WQE_CTRL_CQ_UPDATE | MLX4_WQE_CTRL_SOLICITED); if (mb->m_pkthdr.csum_flags & (CSUM_IP|CSUM_TCP|CSUM_UDP)) { - tx_desc->ctrl.srcrb_flags |= cpu_to_be32(MLX4_WQE_CTRL_IP_CSUM | - MLX4_WQE_CTRL_TCP_UDP_CSUM); + if (mb->m_pkthdr.csum_flags & CSUM_IP) + tx_desc->ctrl.srcrb_flags |= + cpu_to_be32(MLX4_WQE_CTRL_IP_CSUM); + if (mb->m_pkthdr.csum_flags & (CSUM_TCP|CSUM_UDP)) + tx_desc->ctrl.srcrb_flags |= + cpu_to_be32(MLX4_WQE_CTRL_TCP_UDP_CSUM); priv->port_stats.tx_chksum_offload++; } -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Sat Jul 20 14:04:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A1D3A4AD for ; Sat, 20 Jul 2013 14:04:33 +0000 (UTC) (envelope-from mline@ukr.net) Received: from ffe15.ukr.net (ffe15.ukr.net [195.214.192.50]) by mx1.freebsd.org (Postfix) with ESMTP id 578392BF for ; Sat, 20 Jul 2013 14:04:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:Subject:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=AhknabUlNmZ5QuyzOfUqrBsnTJ6Pu22lm9/KagBz1So=; b=ttUe9pkPeqCzm2InHC8cHxUXrkamaMfgG3Cz2NWljv32m9ZflXfzw4aHXZDhuTnb/2ABGgHbS+TrbHYTdULQBmG4SeS2JRqNAIAy9jJwmXrZ1lhfCz/Wi4iJiZKeUsC9KhxuWaRn5oNIFjWDyYjpAjuv1Hd24Hk0HZvYhTiSXwA=; Received: from mail by ffe15.ukr.net with local ID 1V0Xlv-000DsZ-9I for freebsd-net@freebsd.org; Sat, 20 Jul 2013 17:04:31 +0300 MIME-Version: 1.0 Subject: LACP LAGG device problems To: freebsd-net@freebsd.org From: "isp" X-Mailer: freemail.ukr.net 4.0 Message-Id: <53315.1374329071.4500971523820617728@ffe15.ukr.net> Date: Sat, 20 Jul 2013 17:04:31 +0300 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: binary Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Jul 2013 14:04:33 -0000 Hi! Can anybody tell me, is there any plans to improve LAGG(802.3ad) device driver in FreeBSD? It will be greate to have a possibility to set LACP mode (active/passive) and system priority. Also there is no way to set hashing algorithm and master interface (port). And we can't see any information about our neighbor. The same function in Linux is named Bonding and it is much more better. I realy can donate some money to those who can make this improvements. Best regards. >