From owner-freebsd-net@freebsd.org Mon Oct 30 14:09:17 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F126FE5DD1C for ; Mon, 30 Oct 2017 14:09:17 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id D24BD638BF; Mon, 30 Oct 2017 14:09:17 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from blue.vangyzen.net (50-81-65-191.client.mchsi.com [50.81.65.191]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 2149E5646B; Mon, 30 Oct 2017 09:09:17 -0500 (CDT) To: shurd@FreeBSD.org, sbruno@FreeBSD.org, freebsd-net@freebsd.org From: Eric van Gyzen Subject: LOR in iflib_timer Message-ID: <32cdf984-fa30-331c-f7b0-2bec1f13a6cf@FreeBSD.org> Date: Mon, 30 Oct 2017 09:09:13 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 30 Oct 2017 14:09:18 -0000 Twice a day, my router hits an LOR in iflib_timer when it jumps to the "hung" label.  It's running r325049 (head 3 days ago). lock order reversal:  1st 0xfffffe0000f36068 igb1:tx(0):call (igb1:tx(0):call) @ /usr/src/sys/kern/kern_mutex.c:182  2nd 0xfffff80003b0c150 igb1 (iflib ctx lock) @ /usr/src/sys/net/iflib.c:2139 This looks like it was fixed by the big rollup.  If it was fixed by a smallish commit, can that commit alone be merged to head?  If someone can point me to the commit, I'd be happy to test it. Eric From owner-freebsd-net@freebsd.org Mon Oct 30 21:08:36 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 686B4E657C3 for ; Mon, 30 Oct 2017 21:08:36 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E2AE7194B for ; Mon, 30 Oct 2017 21:08:36 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: by mail-qt0-x233.google.com with SMTP id k31so18232921qta.6 for ; Mon, 30 Oct 2017 14:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=8PeDQnyobPe+6QVLBXgqOSH1UNOiCn0MHtd1kymeDVE=; b=lZBewH7GTM7ZatDSpRMM3739uSRDq9W7oM4Actvb3ttdpUP2DudX8/G0TOxpvgfw6j IfUrxLNkZEr/7PiDOnYhW9Uu4/ZdDL2Zcx+S/zSbocBqyaKt+8G02pbHnZ1rrm5P2dmx e5RIP4mrBDZfyXbnOJJMYcVRE6CebvYFDB2zQbGgqFvZyWAXf4vKoti7BmpSWOdrtOEQ m4djN2Y3YsMlfKshD3cOZyS+/fbPAL8E8s37u4vFffTQPpJ8s1c3df9UsSBwv1avtmQ+ MW0CABR+CVGlPtF0xSoEHN5PDZtF+SD/t8CsqR3gAuLiFIbSi14kQxyiOUndeErl4qEz q+IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=8PeDQnyobPe+6QVLBXgqOSH1UNOiCn0MHtd1kymeDVE=; b=eIu81UBWkVsiUm9hqkba77TVkzzvoOOoUz4n6Rbs6tSvvGD6GSoncWx9FfQ5Zs7S6t 1X09EguujLliqMPYfYjcJpFCQzBuqiA/HYZP+p5dUe8cJzbqa6cSfFJcJC7iw2PlwWCn L3e/bF+7sM/1fLeyANh8keOyBAkE0W4oKp8j7ElZCRfD5L/uTFXBZW3e4u6MYpRjwton ATxUujDaFTYFeCAWo7b4Rt6GeOvu6QgaWZx1XK107/hTI0tsJ8gzvphb0br8c0xYDFGI IloygcfypQGDQRUybHf/q9YPjmaJKsM4Fkemogl688LtOHWgROKR3NTLdc+rPeL0uJZp ZJoQ== X-Gm-Message-State: AMCzsaX5Vxxwbnc9XBAgdBu9GkOE4y7ssO+8+oL0HeeIw4349sLDN+Ea BU5jdygwnuBPbH/nLzIJhUrJElRr X-Google-Smtp-Source: ABhQp+R7I1z6nO2Ud1N1rqqxYxCNxsKbJdS+FzysV1GpirVrgB2Ga0Lh4Z7KEqI4Qcq7bovIb9FqWg== X-Received: by 10.237.35.178 with SMTP id j47mr16939266qtc.327.1509397714997; Mon, 30 Oct 2017 14:08:34 -0700 (PDT) Received: from pc.farhan.codes ([2001:470:8:209::dead:c0de]) by smtp.gmail.com with ESMTPSA id a127sm9877083qkc.60.2017.10.30.14.08.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Oct 2017 14:08:34 -0700 (PDT) From: Farhan Khan Subject: VLANing between jails not segmenting traffic To: freebsd-net@freebsd.org Message-ID: <4d50ef1e-1cc2-aca2-d390-313ef824d524@gmail.com> Date: Mon, 30 Oct 2017 17:08:33 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 30 Oct 2017 21:08:36 -0000 Hi all, I am trying to experiment with setting up two jails on different VLANs, but have not been able to segment traffic. My configuration was to create vlan1 for jail1 and vlan2 for jail2. I did the following commands: ifconfig vlan1 create vlan 1 vlandev em0 ifconfig vlan1 10.1.0.1/24 ifconfig vlan2 create vlan 2 vlandev em0 ifconfig vlan2 10.2.0.1/24 Within each jail, I set the interface to be vlan1 and vlan2 and assigned them the IP addresses 10.1.0.2/24 and 10.2.0.2/24, respectively. I can still have connectivity between the two VLANs. Oddly enough, jail1 with IP 10.1.0.2 does not even have a static route outbound at all. An `ifconfig` shows 0xffffff00 (/24) so my expected behavior would be to say "unable to route". It can even connect to the external interface's IP address. At a minimum it should not even know how to connect to the 10.2.0.0/24 network at all. I was advised that its connectivity is because Jails use the base system's routing table. If so, how could one possibly separate network traffic? That's the entire purpose of VLANing. I have been advised to use pf to prevent that, but shouldn't VLANing provide that separation mechanism? I do not know what I might be doing wrong here. Thank you Farhan Khan From owner-freebsd-net@freebsd.org Mon Oct 30 21:26:44 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1045AE65E77 for ; Mon, 30 Oct 2017 21:26:44 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B7E47282F for ; Mon, 30 Oct 2017 21:26:43 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id v9ULQXgH075543 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Oct 2017 22:26:34 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: khanzf@gmail.com Received: from [10.58.0.4] (dadv@[10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id v9ULQPsB070736 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 31 Oct 2017 04:26:25 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: VLANing between jails not segmenting traffic To: Farhan Khan , freebsd-net@freebsd.org References: <4d50ef1e-1cc2-aca2-d390-313ef824d524@gmail.com> From: Eugene Grosbein Message-ID: <59F79902.40408@grosbein.net> Date: Tue, 31 Oct 2017 04:26:26 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <4d50ef1e-1cc2-aca2-d390-313ef824d524@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-Spam-Level: ** X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 30 Oct 2017 21:26:44 -0000 31.10.2017 4:08, Farhan Khan пишет: > Hi all, > > I am trying to experiment with setting up two jails on different VLANs, but have not been able to segment traffic. > > My configuration was to create vlan1 for jail1 and vlan2 for jail2. > > I did the following commands: > ifconfig vlan1 create vlan 1 vlandev em0 > ifconfig vlan1 10.1.0.1/24 > ifconfig vlan2 create vlan 2 vlandev em0 > ifconfig vlan2 10.2.0.1/24 > > Within each jail, I set the interface to be vlan1 and vlan2 and assigned them the IP addresses 10.1.0.2/24 and 10.2.0.2/24, respectively. > > I can still have connectivity between the two VLANs. > > Oddly enough, jail1 with IP 10.1.0.2 does not even have a static route outbound at all. An `ifconfig` shows 0xffffff00 (/24) so my expected behavior would be to say "unable to route". It can even connect to the external interface's IP address. At a minimum it should not even know how to connect to the 10.2.0.0/24 network at all. > > I was advised that its connectivity is because Jails use the base system's routing table. If so, how could one possibly separate network traffic? That's the entire purpose of VLANing. > > I have been advised to use pf to prevent that, but shouldn't VLANing provide that separation mechanism? I do not know what I might be doing wrong here. It seems you are looking for isolated network stacks for jails each having distinct route table etc. You need options VIMAGE for your kernel and create jails with vnet option (man jail) to obtain this feature. From owner-freebsd-net@freebsd.org Mon Oct 30 21:53:20 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 98BFDE66959 for ; Mon, 30 Oct 2017 21:53:20 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 11FBF739EA for ; Mon, 30 Oct 2017 21:53:19 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: (qmail 11471 invoked by uid 89); 30 Oct 2017 21:46:36 -0000 Received: from unknown (HELO ?100.92.203.49?) (mg@grem.de@109.43.1.161) by mail.grem.de with ESMTPA; 30 Oct 2017 21:46:36 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: VLANing between jails not segmenting traffic From: Michael Gmelin X-Mailer: iPhone Mail (14G60) In-Reply-To: <59F79902.40408@grosbein.net> Date: Mon, 30 Oct 2017 22:46:35 +0100 Cc: Farhan Khan , freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <2A44422B-31A9-4ADC-8FCE-D1F8BC03623C@freebsd.org> References: <4d50ef1e-1cc2-aca2-d390-313ef824d524@gmail.com> <59F79902.40408@grosbein.net> To: Eugene Grosbein X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 30 Oct 2017 21:53:20 -0000 > On 30. Oct 2017, at 22:26, Eugene Grosbein wrote: >=20 > 31.10.2017 4:08, Farhan Khan =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> Hi all, >>=20 >> I am trying to experiment with setting up two jails on different VLANs, b= ut have not been able to segment traffic. >>=20 >> My configuration was to create vlan1 for jail1 and vlan2 for jail2. >>=20 >> I did the following commands: >> ifconfig vlan1 create vlan 1 vlandev em0 >> ifconfig vlan1 10.1.0.1/24 >> ifconfig vlan2 create vlan 2 vlandev em0 >> ifconfig vlan2 10.2.0.1/24 >>=20 >> Within each jail, I set the interface to be vlan1 and vlan2 and assigned t= hem the IP addresses 10.1.0.2/24 and 10.2.0.2/24, respectively. >>=20 >> I can still have connectivity between the two VLANs. >>=20 >> Oddly enough, jail1 with IP 10.1.0.2 does not even have a static route ou= tbound at all. An `ifconfig` shows 0xffffff00 (/24) so my expected behavior w= ould be to say "unable to route". It can even connect to the external interf= ace's IP address. At a minimum it should not even know how to connect to the= 10.2.0.0/24 network at all. >>=20 >> I was advised that its connectivity is because Jails use the base system'= s routing table. If so, how could one possibly separate network traffic? Tha= t's the entire purpose of VLANing. >>=20 >> I have been advised to use pf to prevent that, but shouldn't VLANing prov= ide that separation mechanism? I do not know what I might be doing wrong her= e. >=20 > It seems you are looking for isolated network stacks for jails each having= distinct route table etc. > You need options VIMAGE for your kernel and create jails with vnet option (= man jail) > to obtain this feature. >=20 >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" You can use fibs with net.add_addr_allfibs=3D0 to get separate routing table= s (comes with its own set of complications though). -m From owner-freebsd-net@freebsd.org Tue Oct 31 00:04:42 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D37C2E2FBA7 for ; Tue, 31 Oct 2017 00:04:42 +0000 (UTC) (envelope-from freebsd@dukhovni.org) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BDD1A77D7B for ; Tue, 31 Oct 2017 00:04:36 +0000 (UTC) (envelope-from freebsd@dukhovni.org) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 6B88D7A3302 for ; Mon, 30 Oct 2017 23:57:48 +0000 (UTC) (envelope-from freebsd@dukhovni.org) From: Viktor Dukhovni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: FreeBSD 11.1-RELEASE: Kernel panic in ipv6_output() via tcp6_usr_connect() Message-Id: Date: Mon, 30 Oct 2017 19:57:47 -0400 To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.3445.1.7) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 31 Oct 2017 00:04:43 -0000 I am using FreeBSD 11.1 as the O/S for my DANE/SMTP adoption scanner. The system has an IPv4 static IPv4 and also a corresponding 6to4 address on stf0. The system is stable when I run IPv4-only scans, but crashes quickly as soon as I start a bulk scan that also connects to the IPv6 addresses of remote SMTP servers. Indeed after getting the destination address of the connection that caused the panic (see below) I can now reproduce the problem at will with just: $ nc 2a01:5b40:0:2201::1 25 The system has ZFS and two igb network interfaces. The inside network is my RFC1918 home network, so I use ipfw NAT rules for that, and set: ifconfig_igb0=3D"inet ... -tso -txcsum" since hardware checksums don't seem to play along with ipfw and NAT. The scans run on the machine itself, not an internal node. After figuring out how build a debug kernel, and switch off encrypted swap, I got the following stack trace: #0 doadump (textdump=3D) at pcpu.h:222 #1 0xffffffff80a6b6f1 in kern_reboot (howto=3D260) at = /usr/src/sys/kern/kern_shutdown.c:366 #2 0xffffffff80a6bbb0 in vpanic (fmt=3D, ap=3D) at /usr/src/sys/kern/kern_shutdown.c:759 #3 0xffffffff80a6b9e3 in panic (fmt=3D) at = /usr/src/sys/kern/kern_shutdown.c:690 #4 0xffffffff80edf832 in trap_fatal (frame=3D0xfffffe1041cc7260, = eva=3D16) at /usr/src/sys/amd64/amd64/trap.c:801 #5 0xffffffff80edf889 in trap_pfault (frame=3D0xfffffe1041cc7260, = usermode=3D0) at pcpu.h:222 #6 0xffffffff80edf0c6 in trap (frame=3D0xfffffe1041cc7260) at = /usr/src/sys/amd64/amd64/trap.c:421 #7 0xffffffff80ec3641 in calltrap () at = /usr/src/sys/amd64/amd64/exception.S:236 #8 0xffffffff80a49b50 in m_freem (mb=3D0x10) at = /usr/src/sys/kern/kern_mbuf.c:952 #9 0xffffffff80c82b84 in ip6_output (m0=3D0xfffff80049f8e000, = opt=3D, ro=3D0xfffff80329e90530, flags=3D,=20 im6o=3D, ifpp=3D0x0, inp=3D) at /usr/src/sys/netinet6/ip6_output.c:1040 #10 0xffffffff80c53269 in tcp_output (tp=3D0xfffff8027335c820) at = /usr/src/sys/netinet/tcp_output.c:1403 #11 0xffffffff80c60f1b in tcp6_usr_connect (so=3D0xfffff80171dcc6c0, = nam=3D, td=3D0xfffff8017154c000) at = /usr/src/sys/netinet/tcp_usrreq.c:642 #12 0xffffffff80af9bef in kern_connectat (td=3D, = dirfd=3D-100, fd=3D, sa=3D0xfffff803296f3200) at /usr/src/sys/kern/uipc_syscalls.c:584 #13 0xffffffff80af9aa7 in sys_connect (td=3D0xfffff8017154c000, = uap=3D0xfffffe1041cc7930) at /usr/src/sys/kern/uipc_syscalls.c:549 #14 0xffffffff80ee0394 in amd64_syscall (td=3D0xfffff8017154c000, = traced=3D0) at subr_syscall.c:135 #15 0xffffffff80ec392b in Xfast_syscall () at = /usr/src/sys/amd64/amd64/exception.S:396 #16 0x0000000803beee5a in ?? () Peeking at frame 8, it seems that "mb" is not a plausible mbuf pointer: (kgdb) fr 8 #8 0xffffffff80a49b50 in m_freem (mb=3D0x10) at = /usr/src/sys/kern/kern_mbuf.c:952 952 MBUF_PROBE1(m__freem, mb); (kgdb) l 947 */ 948 void 949 m_freem(struct mbuf *mb) 950 { 951 952 MBUF_PROBE1(m__freem, mb); 953 while (mb !=3D NULL) 954 mb =3D m_free(mb); 955 } (kgdb) p mb $1 =3D (struct mbuf *) 0x10 Up a frame up I see: (kgdb) up #9 0xffffffff80c82b84 in ip6_output (m0=3D0xfffff80049f8e000, = opt=3D, ro=3D0xfffff80329e90530, flags=3D,=20 im6o=3D, ifpp=3D0x0, inp=3D) at /usr/src/sys/netinet6/ip6_output.c:1040 1040 m_freem(m0); (kgdb) l 1035 * Remove leading garbages. 1036 */ 1037 sendorfree: 1038 m =3D m0->m_nextpkt; 1039 m0->m_nextpkt =3D 0; 1040 m_freem(m0); 1041 for (m0 =3D m; m; m =3D m0) { 1042 m0 =3D m->m_nextpkt; 1043 m->m_nextpkt =3D 0; 1044 if (error =3D=3D 0) { (kgdb) p *m0 $4 =3D {{m_next =3D 0x10, m_slist =3D {sle_next =3D 0x10}, m_stailq =3D = {stqe_next =3D 0x10}}, {m_nextpkt =3D 0x0, m_slistpkt =3D {sle_next =3D = 0x0}, m_stailqpkt =3D ... Walking further up: (kgdb) up #10 0xffffffff80c53269 in tcp_output (tp=3D0xfffff8027335c820) at = /usr/src/sys/netinet/tcp_output.c:1403 1403 error =3D ip6_output(m, = tp->t_inpcb->in6p_outputopts, (kgdb) l 1398 /* Save packet, if requested. */ 1399 tcp_pcap_add(th, m, &(tp->t_outpkts)); 1400 #endif 1401 1402 /* TODO: IPv6 IP6TOS_ECT bit on */ 1403 error =3D ip6_output(m, = tp->t_inpcb->in6p_outputopts, 1404 &tp->t_inpcb->inp_route6, 1405 ((so->so_options & SO_DONTROUTE) ? = IP_ROUTETOIF : 0), 1406 NULL, NULL, tp->t_inpcb); 1407 (kgdb) up #11 0xffffffff80c60f1b in tcp6_usr_connect (so=3D0xfffff80171dcc6c0, = nam=3D, td=3D0xfffff8017154c000) at = /usr/src/sys/netinet/tcp_usrreq.c:642 642 error =3D tp->t_fb->tfb_tcp_output(tp); (kgdb) l 637 (so->so_options & SO_NO_OFFLOAD) =3D=3D 0 && 638 (error =3D tcp_offload_connect(so, nam)) =3D=3D 0) 639 goto out; 640 #endif 641 tcp_timer_activate(tp, TT_KEEP, TP_KEEPINIT(tp)); 642 error =3D tp->t_fb->tfb_tcp_output(tp); 643 644 out: 645 TCPDEBUG2(PRU_CONNECT); 646 TCP_PROBE2(debug__user, tp, PRU_CONNECT); (kgdb) up #12 0xffffffff80af9bef in kern_connectat (td=3D, = dirfd=3D-100, fd=3D, sa=3D0xfffff803296f3200) at /usr/src/sys/kern/uipc_syscalls.c:584 584 error =3D soconnect(so, sa, td); (kgdb) p *so $2 =3D {so_count =3D 1, so_type =3D 1, so_options =3D 0, so_linger =3D = 0, so_state =3D 260, so_qstate =3D 0, so_pcb =3D 0xfffff80329e903a0, = so_vnet =3D 0x0,=20 so_proto =3D 0xffffffff8198a2c0, so_head =3D 0x0, so_incomp =3D = {tqh_first =3D 0x0, tqh_last =3D 0xfffff80171dcc6f0}, so_comp =3D = {tqh_first =3D 0x0,=20 tqh_last =3D 0xfffff80171dcc700}, so_list =3D {tqe_next =3D 0x0, = tqe_prev =3D 0x0}, so_qlen =3D 0, so_incqlen =3D 0, so_qlimit =3D 0, = so_timeo =3D 0, so_error =3D 0,=20 so_sigio =3D 0x0, so_oobmark =3D 0, so_rcv =3D {sb_sel =3D {si_tdlist = =3D {tqh_first =3D 0x0, tqh_last =3D 0x0}, si_note =3D {kl_list =3D = {slh_first =3D 0x0},=20 kl_lock =3D 0xffffffff80a23fb0 , kl_unlock =3D = 0xffffffff80a23ff0 ,=20 kl_assert_locked =3D 0xffffffff80a24030 = , kl_assert_unlocked =3D 0xffffffff80a24040 = ,=20 kl_lockarg =3D 0xfffff80171dcc790, kl_autodestroy =3D 0}, si_mtx = =3D 0x0}, sb_mtx =3D {lock_object =3D {lo_name =3D 0xffffffff8143469a = "so_rcv", lo_flags =3D 16973824, lo_data =3D 0, lo_witness =3D 0x0}, = mtx_lock =3D 4}, sb_sx =3D {lock_object =3D {lo_name =3D = 0xffffffff814346ab "so_rcv_sx", lo_flags =3D 36896768, lo_data =3D 0, lo_witness =3D 0x0}, = sx_lock =3D 1}, sb_state =3D 0, sb_mb =3D 0x0, sb_mbtail =3D 0x0, = sb_lastrecord =3D 0x0, sb_sndptr =3D 0x0, sb_fnrdy =3D 0x0, sb_sndptroff =3D 0, sb_acc =3D 0, sb_ccc =3D 0, = sb_hiwat =3D 65536, sb_mbcnt =3D 0, sb_mcnt =3D 0, sb_ccnt =3D 0, = sb_mbmax =3D 524288, sb_ctl =3D 0, sb_lowat =3D 1, sb_timeo =3D 0, sb_flags =3D 2048, sb_upcall =3D 0, = sb_upcallarg =3D 0x0, sb_aiojobq =3D {tqh_first =3D 0x0, tqh_last =3D = 0xfffff80171dcc848}, sb_aiotask =3D {ta_link =3D {stqe_next =3D 0x0}, ta_pending =3D 0, = ta_priority =3D 0, ta_func =3D 0xffffffff80ad2450 , = ta_context =3D 0xfffff80171dcc6c0}}, so_snd =3D {sb_sel =3D {si_tdlist =3D {tqh_first =3D 0x0, tqh_last =3D = 0x0}, si_note =3D {kl_list =3D {slh_first =3D 0x0}, kl_lock =3D = 0xffffffff80a23fb0 , kl_unlock =3D 0xffffffff80a23ff0 , = kl_assert_locked =3D 0xffffffff80a24030 , kl_assert_unlocked =3D 0xffffffff80a24040 = , kl_lockarg =3D 0xfffff80171dcc8c8, = kl_autodestroy =3D 0}, si_mtx =3D 0x0}, sb_mtx =3D { lock_object =3D {lo_name =3D 0xffffffff81434693 "so_snd", lo_flags = =3D 16973824, lo_data =3D 0, lo_witness =3D 0x0}, mtx_lock =3D 4}, sb_sx = =3D {lock_object =3D { lo_name =3D 0xffffffff814346a1 "so_snd_sx", lo_flags =3D = 36896768, lo_data =3D 0, lo_witness =3D 0x0}, sx_lock =3D 1}, sb_state =3D= 0, sb_mb =3D 0x0, sb_mbtail =3D 0x0, sb_lastrecord =3D 0x0, sb_sndptr =3D 0x0, = sb_fnrdy =3D 0x0, sb_sndptroff =3D 0, sb_acc =3D 0, sb_ccc =3D 0, = sb_hiwat =3D 32768, sb_mbcnt =3D 0, sb_mcnt =3D 0, sb_ccnt =3D 0, sb_mbmax =3D 262144, sb_ctl =3D 0, = sb_lowat =3D 2048, sb_timeo =3D 0, sb_flags =3D 2048, sb_upcall =3D 0, = sb_upcallarg =3D 0x0, sb_aiojobq =3D {tqh_first =3D 0x0, tqh_last =3D 0xfffff80171dcc980}, = sb_aiotask =3D {ta_link =3D {stqe_next =3D 0x0}, ta_pending =3D 0, = ta_priority =3D 0, ta_func =3D 0xffffffff80ad2d00 , ta_context =3D = 0xfffff80171dcc6c0}}, so_cred =3D 0xfffff80049ca4900, so_label =3D 0x0, = so_peerlabel =3D 0x0, so_gencnt =3D 21655, so_emuldata =3D 0x0, so_accf =3D 0x0, osd =3D = {osd_nslots =3D 0, osd_slots =3D 0x0, osd_next =3D {le_next =3D 0x0, = le_prev =3D 0x0}}, so_fibnum =3D 0, so_user_cookie =3D 0, so_pspare =3D 0xfffff80171dcca08, so_ispare =3D = 0xfffff80171dcca18} (kgdb) p/x (*sa->sa_data)@22 $7 =3D {0x0, 0x19, 0x0, 0x0, 0x0, 0x0, 0x2a, 0x1, 0x5b, 0x40, 0x0, 0x0, = 0x22, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1} So the connection seems to be port 25 (expected), flow info 0, at 2a01:5b40:0:2201::1 (which is mx01.domeneshop.no, also not surprising). Anything further I can report? It seems I'll have to disable IPv6 for now... --=20 Viktor. From owner-freebsd-net@freebsd.org Tue Oct 31 02:10:09 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1FDE4E47BD5 for ; Tue, 31 Oct 2017 02:10:09 +0000 (UTC) (envelope-from shurd@sasktel.net) Received: from mail142c7.megamailservers.com (mail542c7.megamailservers.com [209.235.141.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9C3F680FB5; Tue, 31 Oct 2017 02:10:08 +0000 (UTC) (envelope-from shurd@sasktel.net) X-Authenticated-User: hurds.sasktel.net X-VIP: 69.49.109.87 Received: from [192.168.1.10] (c-98-209-24-48.hsd1.mi.comcast.net [98.209.24.48]) (authenticated bits=0) by mail142c7.megamailservers.com (8.14.9/8.13.1) with ESMTP id v9V22DoC020526; Mon, 30 Oct 2017 22:02:15 -0400 Subject: Re: LOR in iflib_timer To: Eric van Gyzen , shurd@FreeBSD.org, sbruno@FreeBSD.org, freebsd-net@freebsd.org References: <32cdf984-fa30-331c-f7b0-2bec1f13a6cf@FreeBSD.org> From: Stephen Hurd Message-ID: Date: Mon, 30 Oct 2017 22:02:13 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48 MIME-Version: 1.0 In-Reply-To: <32cdf984-fa30-331c-f7b0-2bec1f13a6cf@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CTCH-RefID: str=0001.0A020201.59F7D9A7.007C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.2 cv=BuPt+cf5 c=1 sm=1 tr=0 a=58X0Rtt+oPctIZE0oLz+QA==:117 a=58X0Rtt+oPctIZE0oLz+QA==:17 a=IkcTkHD0fZMA:10 a=6I5d2MoRAAAA:8 a=Awch3riGIH6IYeVObfIA:9 a=QEXdDO2ut3YA:10 a=IjZwj45LgO3ly-622nXo:22 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 31 Oct 2017 02:10:09 -0000 Eric van Gyzen wrote: > Twice a day, my router hits an LOR in iflib_timer when it jumps to the > "hung" label. It's running r325049 (head 3 days ago). > > lock order reversal: > 1st 0xfffffe0000f36068 igb1:tx(0):call (igb1:tx(0):call) @ > /usr/src/sys/kern/kern_mutex.c:182 > 2nd 0xfffff80003b0c150 igb1 (iflib ctx lock) @ > /usr/src/sys/net/iflib.c:2139 > > This looks like it was fixed by the big rollup. If it was fixed by a > smallish commit, can that commit alone be merged to head? If someone > can point me to the commit, I'd be happy to test it. > > Eric I would guess it to be one of the biggest ones. Review here: https://reviews.freebsd.org/D12101 From owner-freebsd-net@freebsd.org Tue Oct 31 11:35:48 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BDA73E562B9 for ; Tue, 31 Oct 2017 11:35:48 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward105j.mail.yandex.net (forward105j.mail.yandex.net [5.45.198.248]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5BA0F7075A for ; Tue, 31 Oct 2017 11:35:47 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback4j.mail.yandex.net (mxback4j.mail.yandex.net [IPv6:2a02:6b8:0:1619::10d]) by forward105j.mail.yandex.net (Yandex) with ESMTP id 6AF161824B8; Tue, 31 Oct 2017 14:35:39 +0300 (MSK) Received: from smtp1j.mail.yandex.net (smtp1j.mail.yandex.net [2a02:6b8:0:801::ab]) by mxback4j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id D1oAtKrf4i-ZdtmPRtu; Tue, 31 Oct 2017 14:35:39 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1509449739; bh=Pd+JrUFmu27AMHADYDaQhD5sj20uUQbw1GFZKAOKVVQ=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=tv2fjxvq+Qr6YLD6AiM/2am52AyEtCi9Aui+wKYDPk7tG7t17pEEYNc82Ev0rkubX ebaPwUSMnwlqpgTKyHwx9hgx9axSeMj4x01YgymNsYztFwW6hmMJM2A+rxptKfjKLK PBpRz5wBbcqH++JQOfZw1SaaqF1cOXNld7SGifqA= Received: by smtp1j.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id ghwCbrnNo2-ZckqNK1G; Tue, 31 Oct 2017 14:35:38 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1509449738; bh=Pd+JrUFmu27AMHADYDaQhD5sj20uUQbw1GFZKAOKVVQ=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=fQcv12qfNSgtvLqGeWa3C5ujU817cx07uXHY922NGG/vfpOWC07SRgwSRh7pUySwi idPsVJ47OtsT6A1BUo83pK6bg5ihsqN4yuIpp5xzcrYIoBvPh5cCaa78m0XrHi+7Z7 gm1hKcGX28y0zsvcnYK07S1FQ69V051HQZYZgabE= Authentication-Results: smtp1j.mail.yandex.net; dkim=pass header.i=@yandex.ru Subject: Re: FreeBSD 11.1-RELEASE: Kernel panic in ipv6_output() via tcp6_usr_connect() To: Viktor Dukhovni , freebsd-net@freebsd.org References: From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Message-ID: <86dcc06d-b98c-cc1f-8726-8afb011871e3@yandex.ru> Date: Tue, 31 Oct 2017 14:34:52 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dQMN28HhVb6hB6H9jq05S5LFF3m4Vsjk8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 31 Oct 2017 11:35:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dQMN28HhVb6hB6H9jq05S5LFF3m4Vsjk8 Content-Type: multipart/mixed; boundary="FM2kQ5bHGKun2WU6WOuJUwbcFBUCi3B4T"; protected-headers="v1" From: "Andrey V. Elsukov" To: Viktor Dukhovni , freebsd-net@freebsd.org Message-ID: <86dcc06d-b98c-cc1f-8726-8afb011871e3@yandex.ru> Subject: Re: FreeBSD 11.1-RELEASE: Kernel panic in ipv6_output() via tcp6_usr_connect() References: In-Reply-To: --FM2kQ5bHGKun2WU6WOuJUwbcFBUCi3B4T Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 31.10.2017 02:57, Viktor Dukhovni wrote: > I am using FreeBSD 11.1 as the O/S for my DANE/SMTP adoption scanner. > The system has an IPv4 static IPv4 and also a corresponding 6to4 > address on stf0. >=20 > The system is stable when I run IPv4-only scans, but crashes quickly > as soon as I start a bulk scan that also connects to the IPv6 addresses= > of remote SMTP servers. Indeed after getting the destination address > of the connection that caused the panic (see below) I can now reproduce= > the problem at will with just: >=20 > $ nc 2a01:5b40:0:2201::1 25 >=20 > since hardware checksums don't seem to play along with ipfw and NAT. > The scans run on the machine itself, not an internal node. >=20 > #9 0xffffffff80c82b84 in ip6_output (m0=3D0xfffff80049f8e000, opt=3D, ro=3D0xfffff80329e90530, flags=3D,=20 > im6o=3D, ifpp=3D0x0, inp=3D) at /usr/src/sys/netinet6 Hi, can you show your nat rules? Also what will show following commands in kgdb: f 9 i lo p *ifp p *ro p *m --=20 WBR, Andrey V. Elsukov --FM2kQ5bHGKun2WU6WOuJUwbcFBUCi3B4T-- --dQMN28HhVb6hB6H9jq05S5LFF3m4Vsjk8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAln4X90ACgkQAcXqBBDI oXqE5QgAgkhHicUmaP7HZI8eviOLd/iKpztgykcXQ8VJSw/QDRAhxDP4eEdSM2uo wr0qUGkJg2YWwi5cWeqBwes1N9Hqa7+TEJ20Jw3eq8zVfu0OwA/WmNK0q19AFjrt Sl2TeuAX785EZ6hYk8/9GziPJ80RyAVhrnUeZdOsnpToD+6PXwdeE4+ejIW7Bis3 HLPL0FUte1biCUDtxDvkghh7qSv6N1+vfRxsAdj78o57RvObMEbvqKU0n2nUvyzg YADEHDIPEmlkUjPFmicUIrFThuIIdCFRssiCZgXyU99TqQKc9WvPTLU5ZdjbYgmz IsJodAxQoPmpbRNkk3S/zccA777PeA== =1wmH -----END PGP SIGNATURE----- --dQMN28HhVb6hB6H9jq05S5LFF3m4Vsjk8-- From owner-freebsd-net@freebsd.org Tue Oct 31 15:13:52 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5AFFAE5C7FE for ; Tue, 31 Oct 2017 15:13:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4949E7DEA6 for ; Tue, 31 Oct 2017 15:13:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v9VFDqj1052663 for ; Tue, 31 Oct 2017 15:13:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 221919] ixl: TX queue hang when using TSO and having a high and mixed network load Date: Tue, 31 Oct 2017 15:13:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: peter@ifm.liu.se X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 31 Oct 2017 15:13:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221919 Peter Eriksson changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |peter@ifm.liu.se --- Comment #2 from Peter Eriksson --- This is a really annoying bug that we've also seen. I do not think it's rel= ated to iSCSI though (since we aren't using it). Disabling TSO seems to help (but also severly reduces transmission speed - in our case it drops from around 10Gbps to 3Gbps without TSO). I our servers are SMB (and NFS, but not much yet) servers. Dell PowerEdge 730xd. > FreeBSD 11.1 > ixl2: fw 5.40.47690 api 1.5 nvm 5.40 etid 80002d35 oem 18.4608.16 ixl0: Link is up, 10 Gbps Full Duplex, FEC: None, Autoneg: False, Flow Cont= rol: Full ixl0: link state changed to UP ixl2: Link is up, 10 Gbps Full Duplex, FEC: None, Autoneg: False, Flow Cont= rol: Full ixl2: link state changed to UP ixl0: = mem 0xc9000000-0xc9ffffff,0xca008000-0xca00ffff at device 0.0 numa-domain 1 on pci15 ixl0: Using MSIX interrupts with 9 vectors ixl0: fw 5.40.47690 api 1.5 nvm 5.40 etid 80002d35 oem 18.4608.16 ixl0: PF-ID[0]: VFs 64, MSIX 129, VF MSIX 5, QPs 768, I2C ixl0: Allocating 8 queues for PF LAN VSI; 8 queues active ixl0: Ethernet address: 3c:fd:fe:24:e7:e0 ixl0: PCI Express Bus: Speed 8.0GT/s Width x8 ixl0: Failed to initialize SR-IOV (error=3D2) ixl0: netmap queues/slots: TX 8/1024, RX 8/1024 ixl2: = mem 0xcc000000-0xccffffff,0xcd008000-0xcd00ffff at device 0.0 numa-domain 1 on pci16 ixl2: Using MSIX interrupts with 9 vectors ixl2: fw 5.40.47690 api 1.5 nvm 5.40 etid 80002d35 oem 18.4608.16 ixl2: PF-ID[0]: VFs 64, MSIX 129, VF MSIX 5, QPs 768, I2C ixl2: Allocating 8 queues for PF LAN VSI; 8 queues active ixl2: Ethernet address: 3c:fd:fe:24:d6:a0 ixl2: PCI Express Bus: Speed 8.0GT/s Width x8 ixl2: Failed to initialize SR-IOV (error=3D2) ixl2: netmap queues/slots: TX 8/1024, RX 8/1024 ixl0: Link is up, 10 Gbps Full Duplex, FEC: None, Autoneg: False, Flow Cont= rol: Full ixl0: link state changed to UP ixl2: Link is up, 10 Gbps Full Duplex, FEC: None, Autoneg: False, Flow Cont= rol: Full ixl2: link state changed to UP ixl2: link state changed to DOWN ixl0: link state changed to DOWN ixl0: Link is up, 10 Gbps Full Duplex, FEC: None, Autoneg: False, Flow Cont= rol: Full ixl0: link state changed to UP ixl2: Link is up, 10 Gbps Full Duplex, FEC: None, Autoneg: False, Flow Cont= rol: Full ixl2: link state changed to UP ixl2: Malicious Driver Detection event 2 on TX queue 0, pf number 0 ixl2: MDD TX event is for this function!ixl2: Interface stopped DISTRIBUTIN= G, possible flapping ixl2: Interface stopped DISTRIBUTING, possible flapping ixl2: Interface stopped DISTRIBUTING, possible flapping ...repeat... ixl2: WARNING: queue 0 appears to be hung! ixl2: WARNING: Resetting! I managed to login to the server after a while and disable TSO and then thi= ngs started working again. Would using the Intel-provided (instead of the 11.1 one) driver and firmware (from their web site) help with this issue? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Oct 31 16:40:24 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8E3DE5E5EC for ; Tue, 31 Oct 2017 16:40:24 +0000 (UTC) (envelope-from freebsd@dukhovni.org) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 84F6980917 for ; Tue, 31 Oct 2017 16:40:23 +0000 (UTC) (envelope-from freebsd@dukhovni.org) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id AE7937A3302 for ; Tue, 31 Oct 2017 16:40:21 +0000 (UTC) (envelope-from freebsd@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: Re: FreeBSD 11.1-RELEASE: Kernel panic in ipv6_output() via tcp6_usr_connect() From: Viktor Dukhovni In-Reply-To: <86dcc06d-b98c-cc1f-8726-8afb011871e3@yandex.ru> Date: Tue, 31 Oct 2017 12:40:20 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: freebsd-net@freebsd.org Message-Id: References: <86dcc06d-b98c-cc1f-8726-8afb011871e3@yandex.ru> To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.3445.1.7) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 31 Oct 2017 16:40:25 -0000 > On Oct 31, 2017, at 7:34 AM, Andrey V. Elsukov = wrote: >=20 > can you show your nat rules? Sure, igb0 is outside, igb1 is inside, the external IP address is 100.2.39.101/24, the internal is 192.168.1.1/24. The machine is the DNS server for the inside network and does not NAT DNS traffic (makes thousands of DNS queries per second when doing DANE scans, and would quickly exhaust the state tables). I also don't NAT NTP, or TCP 22/88 to the server. There's no IPv6 on the internal network, so at present the IPv6 rules are rudimentary, just anti-spoof the loopback interface and boilerplate ICMP6 rules. $ cat /etc/rc.homenet #! /bin/sh oif=3Digb0 oaddr=3D100.2.39.101 iif=3Digb1 inet=3D192.168.1.0/24 iaddr=3D192.168.1.1 ipfw() { command ipfw -q "$@"; } kldload -n libalias kldload -n ipfw_nat ipfw -f flush ipfw table 1 flush # RFC 1918 addresses ipfw table 1 add 10.0.0.0/8 ipfw table 1 add 172.16.0.0/12 ipfw table 1 add 192.168.0.0/16 # reserved addresses ipfw table 1 add 0.0.0.0/8 ipfw table 1 add 169.254.0.0/16 ipfw table 1 add 192.0.2.0/24 ipfw table 1 add 224.0.0.0/4 ipfw table 1 add 240.0.0.0/4 # Block RFC1918 and reserved addresses on outside interface ipfw add deny all from any to "table(1)" via ${oif} # Anti-spoof loopback ipfw add allow ip from any to any via lo0 ipfw add deny ip from any to 127.0.0.0/8 ipfw add deny ip from 127.0.0.0/8 to any ipfw add deny ip from any to ::1 ipfw add deny ip from ::1 to any # V6 icmp ipfw add allow ipv6-icmp from :: to ff02::/16 ipfw add allow ipv6-icmp from fe80::/10 to fe80::/10 ipfw add allow ipv6-icmp from fe80::/10 to ff02::/16 ipfw add allow ipv6-icmp from any to any ip6 icmp6types 1 ipfw add allow ipv6-icmp from any to any ip6 icmp6types 2,135,136 # Anti-spoof inside and outside ipfw add deny ip from $inet to any in via "${oif}" ipfw add deny ip from $oaddr to any in via "${oif}" ipfw add deny ip from not $inet to any in via "${iif}" ipfw add deny ip from $iaddr to any in via "${iif}" # NAT exceptions: # All DNS traffic ipfw add allow tcp from any 53 to me ipfw add allow udp from any 53 to me ipfw add allow udp from me to any dst-port 53 ipfw add allow tcp from me to any dst-port 53 ipfw add allow tcp from any to me dst-port 53 ipfw add allow udp from any to me dst-port 53 ipfw add allow udp from me 53 to any ipfw add allow tcp from me 53 to any # My NTP server ipfw add allow tcp from any 123 to me dst-port 123 ipfw add allow udp from any 123 to me dst-port 123 ipfw add allow udp from me 123 to any dst-port 123 ipfw add allow tcp from me 123 to any dst-port 123 # My SSH server ipfw add allow tcp from any to me dst-port 22 ipfw add allow tcp from me 22 to any # My KDC ipfw add allow tcp from any to me dst-port 88 ipfw add allow tcp from me 88 to any # NAT the rest ipfw nat 1 config if "$oif" unreg_only reset same_ports ipfw add nat 1 ip from any to any via "$oif" # Drop reserved addresses that fail to NAT ipfw add deny ip from "table(1)" to any via "$oif" # Permit the rest ipfw add allow ip from any to any > Also what will show following commands in kgdb: >=20 > f 9 > i lo m =3D hdrsplit =3D unfragpartlen =3D 40 plen =3D optlen =3D error =3D 0 exthdrs =3D {ip6e_ip6 =3D 0x0, ip6e_hbh =3D 0x0, ip6e_dest1 =3D 0x0, = ip6e_rthdr =3D 0x0, ip6e_dest2 =3D 0x0} ip6 =3D nexthdrp =3D mprev =3D ro_pmtu =3D hlen =3D 40 dst =3D (struct sockaddr_in6 *) 0xfffff800118bed60 ia =3D fwd_tag =3D (struct m_tag *) 0x0 dst0 =3D {__u6_addr =3D {__u6_addr8 =3D 0xfffffe1041cc7398 "*\001[@", = __u6_addr16 =3D 0xfffffe1041cc7398,=20 __u6_addr32 =3D 0xfffffe1041cc7398}} src_sa =3D {sin6_len =3D 28 '\034', sin6_family =3D 28 '\034', sin6_port = =3D 0, sin6_flowinfo =3D 0, sin6_addr =3D {__u6_addr =3D { __u6_addr8 =3D 0xfffffe1041cc7350 " \002d\002'e", __u6_addr16 =3D = 0xfffffe1041cc7350, __u6_addr32 =3D 0xfffffe1041cc7350}},=20 sin6_scope_id =3D 0} origifp =3D (struct ifnet *) 0xfffff8001006b000 src0 =3D {__u6_addr =3D {__u6_addr8 =3D 0xfffffe1041cc7388 " = \002d\002'e", __u6_addr16 =3D 0xfffffe1041cc7388,=20 __u6_addr32 =3D 0xfffffe1041cc7388}} dst_sa =3D {sin6_len =3D 28 '\034', sin6_family =3D 28 '\034', sin6_port = =3D 0, sin6_flowinfo =3D 0, sin6_addr =3D {__u6_addr =3D { __u6_addr8 =3D 0xfffffe1041cc7470 "*\001[@", __u6_addr16 =3D = 0xfffffe1041cc7470, __u6_addr32 =3D 0xfffffe1041cc7470}},=20 sin6_scope_id =3D 0} fibnum =3D rt =3D (struct rtentry *) 0xfffff80022ecfd00 ifp =3D zone =3D mtu =3D needfiblookup =3D tso =3D sw_csum =3D len =3D 1448 id =3D > p *ifp (kgdb) p *ifp Cannot access memory at address 0x1300000049 > p *ro (kgdb) p *ro $1 =3D {ro_rt =3D 0xfffff80022ecfd00, ro_lle =3D 0x0, ro_prepend =3D = 0x0, ro_plen =3D 0, ro_flags =3D 256, ro_mtu =3D 0, spare =3D 0, ro_dst = =3D { sin6_len =3D 28 '\034', sin6_family =3D 28 '\034', sin6_port =3D 0, = sin6_flowinfo =3D 0, sin6_addr =3D {__u6_addr =3D { __u6_addr8 =3D 0xfffff80329e90558 "*\001[@", __u6_addr16 =3D = 0xfffff80329e90558, __u6_addr32 =3D 0xfffff80329e90558}},=20 sin6_scope_id =3D 0}} > p *m (kgdb) p *m $2 =3D {{m_next =3D 0xfffff80022ecfd00, m_slist =3D {sle_next =3D = 0xfffff80022ecfd00}, m_stailq =3D {stqe_next =3D 0xfffff80022ecfd00}}, { m_nextpkt =3D 0x0, m_slistpkt =3D {sle_next =3D 0x0}, m_stailqpkt =3D = {stqe_next =3D 0x0}}, m_data =3D 0x0, m_len =3D 16777216,=20 m_type =3D 0, m_flags =3D 0, {{m_pkthdr =3D {rcvif =3D 0x1c1c, tags =3D = {slh_first =3D 0x1220000405b012a}, len =3D 0, flowid =3D 16777216,=20 csum_flags =3D 0, fibnum =3D 1856, cosqos =3D 233 '=EF=BF=BD', = rsstype =3D 41 ')', l2hlen =3D 3 '\003', l3hlen =3D 248 '=EF=BF=BD',=20 l4hlen =3D 255 '=EF=BF=BD', l5hlen =3D 255 '=EF=BF=BD', PH_per =3D= {eight =3D 0xfffff80329e90578 "=EF=BF=BD=EF=BF=BD6\017", sixteen =3D = 0xfffff80329e90578,=20 thirtytwo =3D 0xfffff80329e90578, sixtyfour =3D = 0xfffff80329e90578, unintptr =3D 0xfffff80329e90578,=20 ptr =3D 0xfffffe000f36c3e0}, PH_loc =3D {eight =3D = 0xfffff80329e90580 "", sixteen =3D 0xfffff80329e90580,=20 thirtytwo =3D 0xfffff80329e90580, sixtyfour =3D = 0xfffff80329e90580, unintptr =3D 0xfffff80329e90580, ptr =3D 0x0}}, = {m_ext =3D {{ ext_count =3D 0, ext_cnt =3D 0x0}, ext_buf =3D = 0xfffff80329e90740 "", ext_size =3D 2178721104, ext_type =3D 255,=20 ext_flags =3D 16777215, ext_free =3D 0, ext_arg1 =3D = 0xffffffff81dca558, ext_arg2 =3D 0x0},=20 m_pktdat =3D 0xfffff80329e90588 ""}}, m_dat =3D = 0xfffff80329e90550 "\034\034"}} --=20 Viktor. From owner-freebsd-net@freebsd.org Tue Oct 31 17:41:44 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EDC27E5FAD2 for ; Tue, 31 Oct 2017 17:41:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A1D5E82C06 for ; Tue, 31 Oct 2017 17:41:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v9VHfijK026845 for ; Tue, 31 Oct 2017 17:41:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 221919] ixl: TX queue hang when using TSO and having a high and mixed network load Date: Tue, 31 Oct 2017 17:41:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rstone@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 31 Oct 2017 17:41:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221919 Ryan Stone changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rstone@FreeBSD.org --- Comment #3 from Ryan Stone --- How reproducible is the hang? Could you please try this patch and confirm whether it fixes your issue? https://people.freebsd.org/~rstone/patches/ixl_tsosegpermss.diff --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Nov 1 11:18:43 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0DFADE5800E for ; Wed, 1 Nov 2017 11:18:43 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward104o.mail.yandex.net (forward104o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::607]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A321B697F5 for ; Wed, 1 Nov 2017 11:18:42 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback17j.mail.yandex.net (mxback17j.mail.yandex.net [IPv6:2a02:6b8:0:1619::93]) by forward104o.mail.yandex.net (Yandex) with ESMTP id 7EC9F70205D; Wed, 1 Nov 2017 14:18:29 +0300 (MSK) Received: from smtp1j.mail.yandex.net (smtp1j.mail.yandex.net [2a02:6b8:0:801::ab]) by mxback17j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id VKrdn3NKks-IS1GlxND; Wed, 01 Nov 2017 14:18:29 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1509535109; bh=7iE2CA8/seI1cQwCtwxERxg7qmPNUXN4ZvFCCLkbQ88=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=W2CHpfGmxSBIlNP6Dc8Z3nITTW2Y5ptb8xg/loCEWrUW2ctCONGjq9+OmOs6XSeqZ 7z9rIwEGSWkcZYNnp2UTn6UzAkA6Ngg4iDYYym5X+X5H5D/wdMgox4glyVW2Z3DX2w /ZJAXWkOYduvhNNAbaDtyc63PHFNe4GaHfrR6NuU= Received: by smtp1j.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id FpKqziWuZH-IRXSJoMA; Wed, 01 Nov 2017 14:18:28 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1509535108; bh=7iE2CA8/seI1cQwCtwxERxg7qmPNUXN4ZvFCCLkbQ88=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=DPGdtXGN0TlkA2/IHp6ckdbVtxGczpr4A8vKfdpGpCSPk6y5IRnXBIjeime0gV3qE wlua3DKVwZ+OIaTa1PcfGmcUTgeGx+foPFm6LUhfBIYQwXAMpQ6KwHBoGN+j+v6wij KYg2Sba2teLOmNQxI6e7kuphZvOB3J/8O+1O8ysc= Authentication-Results: smtp1j.mail.yandex.net; dkim=pass header.i=@yandex.ru Subject: Re: FreeBSD 11.1-RELEASE: Kernel panic in ipv6_output() via tcp6_usr_connect() To: freebsd-net@freebsd.org, Viktor Dukhovni References: <86dcc06d-b98c-cc1f-8726-8afb011871e3@yandex.ru> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Message-ID: <94e12e46-f54a-ae22-3f4c-0bd9ac7e1fc9@yandex.ru> Date: Wed, 1 Nov 2017 14:17:33 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fMnIglqx5UMP0Tn0mCbbXUTingGCsBNec" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 01 Nov 2017 11:18:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fMnIglqx5UMP0Tn0mCbbXUTingGCsBNec Content-Type: multipart/mixed; boundary="Bvbi2wePqo6FfHat84UI3D6I3uwCxUMbB"; protected-headers="v1" From: "Andrey V. Elsukov" To: freebsd-net@freebsd.org, Viktor Dukhovni Message-ID: <94e12e46-f54a-ae22-3f4c-0bd9ac7e1fc9@yandex.ru> Subject: Re: FreeBSD 11.1-RELEASE: Kernel panic in ipv6_output() via tcp6_usr_connect() References: <86dcc06d-b98c-cc1f-8726-8afb011871e3@yandex.ru> In-Reply-To: --Bvbi2wePqo6FfHat84UI3D6I3uwCxUMbB Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 31.10.2017 19:40, Viktor Dukhovni wrote: >> can you show your nat rules? >=20 > Sure, igb0 is outside, igb1 is inside, the external IP > address is 100.2.39.101/24, the internal is 192.168.1.1/24. > The machine is the DNS server for the inside network and > does not NAT DNS traffic (makes thousands of DNS queries > per second when doing DANE scans, and would quickly exhaust > the state tables). I also don't NAT NTP, or TCP 22/88 to > the server. There's no IPv6 on the internal network, so > at present the IPv6 rules are rudimentary, just anti-spoof > the loopback interface and boilerplate ICMP6 rules. > # NAT the rest > ipfw nat 1 config if "$oif" unreg_only reset same_ports > ipfw add nat 1 ip from any to any via "$oif" Just an theory, can you try change this rule to be like this: ipfw add nat 1 ip4 from any to any via "$oif" =46rom first glance I don't see any restrictions in libalias/nat44 to not= try to translate IPv6 packet assuming it as IPv4. --=20 WBR, Andrey V. Elsukov --Bvbi2wePqo6FfHat84UI3D6I3uwCxUMbB-- --fMnIglqx5UMP0Tn0mCbbXUTingGCsBNec Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAln5rU0ACgkQAcXqBBDI oXqLEwgAsRfE6+inhCGmQ2s1Dxt9LuOLp/GRLZU0lICk1EnwyA1d8fXmP89T4cH2 PqcyxUzhLIGPwubXqhYMPOes/nliGhal661pvEZO1aDMkZjFqhPWvbNyA+72IL5T qwTJWzajXykrVJFF3nUdtp0cPUDs6ijqauQ+GGOqi5EbBTQvp8SAmphpJo5/E/GW NdtCm9UqAWruF+itX6L+EKEgF1sfRL/nOh2Qm9ectjVINzS39ug6s0s/mtgM345L xA5OlbFKDcrPbJcEYP27bjremcsKL8lFptgo7Nov/e43ZTVVr2D0I11lBqpq+50F ohcljOHKEtilDRLVTM6cxKwUqK896g== =MBMy -----END PGP SIGNATURE----- --fMnIglqx5UMP0Tn0mCbbXUTingGCsBNec-- From owner-freebsd-net@freebsd.org Wed Nov 1 15:01:31 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04760E5DC84 for ; Wed, 1 Nov 2017 15:01:31 +0000 (UTC) (envelope-from ml@netfence.it) Received: from smtp209.alice.it (smtp209.alice.it [82.57.200.105]) by mx1.freebsd.org (Postfix) with ESMTP id 92F3A718B4 for ; Wed, 1 Nov 2017 15:01:29 +0000 (UTC) (envelope-from ml@netfence.it) Received: from soth.ventu (212.171.20.179) by smtp209.alice.it (8.6.060.28) id 59A3DB800931D132 for freebsd-net@freebsd.org; Wed, 1 Nov 2017 16:01:24 +0100 Received: from alamar.ventu (alamar.local.netfence.it [10.1.2.18]) by soth.ventu (8.15.2/8.15.2) with ESMTP id vA1F1NQG053803 for ; Wed, 1 Nov 2017 16:01:23 +0100 (CET) (envelope-from ml@netfence.it) X-Authentication-Warning: soth.ventu: Host alamar.local.netfence.it [10.1.2.18] claimed to be alamar.ventu From: Andrea Venturoli Subject: Help provisioning a Samba AD in a jail on ZFS To: freebsd-net@freebsd.org Message-ID: <57dc8e1e-6e38-456d-f70d-291d6bf68bb8@netfence.it> Date: Wed, 1 Nov 2017 16:01:18 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 01 Nov 2017 15:01:31 -0000 Hello. As per subject, I'm building a new box which must host a jail running a Samba AD, but I have trouble provisioning it. Currently I'm trying samba44. I read a lot of material and I think I understand the problem: it seems the "samba-tool provision" script is incompatible with NFSv4ACL used by ZFS. AFAICT this issue has been raised, the Samba team has acknowledged a patch should be made, but so far nothing happened. So I'm looking into workarounds: a) someone suggest installing samba43, provision, then upgrade to samba44. In fact this is some path I went through a couple of times in the past (on UFS, however). Alas samba43 is no longer there. b) I think I might get around this by provisioning with the deprecated NTVFS, then switch to S3FS. Unfortunately samba44 does not build NTVFS anymore, unless the DEVELOPER option is used; but if the DEVELOPER option is used compilation (on Poudriere) fails with: > ../source4/lib/socket/socket_ip.c:864:12: error: comparison of array 'addr.__u6_addr.__u6_addr8' equal to a null pointer is always false [-Werror,-Wtautological-pointer-compare] > if (addr.s6_addr == 0) { > ~~~~~^~~~~~~ ~ > /usr/include/netinet6/in6.h:103:29: note: expanded from macro 's6_addr' > #define s6_addr __u6_addr.__u6_addr8 > ^ > 1 error generated. c) I tried creating a ZVOL, formatting it with UFS, mounting it with ACLs inside the jail, but still provisioning says I have no ACL support. d) I know samba46 is incompatible with jails (at least as AD DC), but didn't try samba45. AFAICT, however, nothing should have improved WRT to my problem. So, after spending a couple of days on this and before spending another week trying every path, I tought I'd ask... Should I temporarily revive samba43? Can samba44 with NTVFS compilation error be fixed? Should I try samba45 or is it just a waste of time? Would creating a jail on another (UFS) box and then moving /var/db/samba4 and smb4.conf here work? I'm open to any other suggestion as long as the objective (AD in a jail on ZFS) is met in the end. bye & Thanks av. From owner-freebsd-net@freebsd.org Wed Nov 1 15:35:57 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A408E5E573; Wed, 1 Nov 2017 15:35:57 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id 41F467295D; Wed, 1 Nov 2017 15:35:57 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.19.110] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 48BCBF64; Wed, 1 Nov 2017 18:35:49 +0300 (MSK) To: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Reply-To: lev@FreeBSD.org From: Lev Serebryakov Subject: Low default setting of UDBHASHSIZE leads to unresponsive system Organization: FreeBSD Message-ID: Date: Wed, 1 Nov 2017 18:35:43 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wit383s75hew81jjR4RBrW6HQK8cBIgFB" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 01 Nov 2017 15:35:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wit383s75hew81jjR4RBrW6HQK8cBIgFB Content-Type: multipart/mixed; boundary="wjfLrliuG7HlGAqsBuXDWuLl3TCuIwtfX"; protected-headers="v1" From: Lev Serebryakov Reply-To: lev@FreeBSD.org To: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Message-ID: Subject: Low default setting of UDBHASHSIZE leads to unresponsive system --wjfLrliuG7HlGAqsBuXDWuLl3TCuIwtfX Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Now 11-STABLE (and 12-CURRENT too) have this: sys/netinet/udp_usrreq.c:#define UDBHASHSIZE 128 Looks like such low value could lead to 100% consumption of CPU by interrupt threads (igb queues in my case) on heavy incoming UDP traffic (torrents with uTP in my case). My system (E3-1220v3 with I210 NICs) becomes completely unresponsive (nut complains about lost connection to UPS, ssh to system times out, etc) when system downloads torrent with many uTP (UDP) peers. Four igb0 queues consume 100% CPU each in this scenario. Total traffic could be very low like 500KiB/s (yes, 500KiB/s, not MiB/s!), I don't speak about 1Gbit/s or even 100Mbit/s here! Rebuilding kernel with UDBHASHSIZE=3D16384 seems to help. Why is this value so low and why I need to patch sources to change it? Many such settings are changeable via sysctl and/or tunables, but this one looks hardcoded. --=20 // Lev Serebryakov --wjfLrliuG7HlGAqsBuXDWuLl3TCuIwtfX-- --wit383s75hew81jjR4RBrW6HQK8cBIgFB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE+W0coLX0MYtnSzMK6rA8WL/cR48FAln56c9fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEY5 NkQxQ0EwQjVGNDMxOEI2NzRCMzMwQUVBQjAzQzU4QkZEQzQ3OEYACgkQ6rA8WL/c R4/rQQ/8CsqPftmBflc7rJGdKg6vg+lKqPu4hG58x6I/8Iia6+r+m3XYSbOiyK6F LRNABz6AcEutv/6ctAchX9Gs+zvtP7qylowqxypJG+BoIXEIXFfrbn1B+yMJ2Tws 7M9EcpRxuHKIdzq5QHq3d/3w3h1muzL9z6V1k451UXfyJkGJXeYLtiuPqZGAJ90L 6lOi6NkE9Q8mc0OqhnIEfedXIVLN28OTlItSGHjKGKt2XSUGEvysy4WhLtXTIaF1 B66M5mPSqKhaexKiIiNKMzA5bw+Rh98HMo2u6+6nhh8JxVnmNPd0GDj/ziAuXNE2 zkiCqjOiU4h3yh6AqwJ0OC7pGMlIYy5Dm4TmSG055hV5SsO0045NucNJJXLOmuH6 /WHibM6xcLKqVmlQR2i9cMhlSwXQh4SlWNWe2gXsEc3XbF95ToACR4Jxrk3AKA8f 2m53K2Q3Sqsh26d4UCCNYQeVA0hwLOkRFihmZVH8u7L8/vXlxtB+n8CU4JfP0+Ri txyVgDo2hTD4JuNXGzB9d1Hvl9+Fi/Qbb6+fWardwdKewvNzXZuUcWzInvc/41vw LYqQPeTWO8G+2fPzP4uhZFizvsSyQm1jxwXBh3XtMJ0a7NrwJDhil0tKl5kpqVSU OvxxJHvBuMGfq6/bjJ3RUEXCmFzd+LMn+UrliZhAa4Eut+ybN7I= =jvBK -----END PGP SIGNATURE----- --wit383s75hew81jjR4RBrW6HQK8cBIgFB-- From owner-freebsd-net@freebsd.org Wed Nov 1 21:53:35 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F54FE65427 for ; Wed, 1 Nov 2017 21:53:35 +0000 (UTC) (envelope-from 3des@inx.su) Received: from relay12.nicmail.ru (relay12.nicmail.ru [195.208.5.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC99F83689 for ; Wed, 1 Nov 2017 21:53:32 +0000 (UTC) (envelope-from 3des@inx.su) Received: from [109.70.25.215] (port=38125 helo=[192.168.35.23]) by f06.mail.nic.ru with esmtp (Exim 5.55) (envelope-from <3des@inx.su>) id 1eA0qA-000Duv-30 for freebsd-net@freebsd.org; Thu, 02 Nov 2017 00:46:26 +0300 Received: from [37.190.110.16] (account 3des@inx.su HELO [192.168.35.23]) by proxy02.mail.nic.ru (Exim 5.55) with id 1eA0q7-0006wG-Q8 for freebsd-net@freebsd.org; Thu, 02 Nov 2017 00:46:23 +0300 To: freebsd-net@freebsd.org From: DES <3des@inx.su> Subject: IP packet header visualization software Message-ID: <6de334e9-8962-e43d-006d-8bc2fe4ec1ea@inx.su> Date: Thu, 2 Nov 2017 00:46:25 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 01 Nov 2017 21:53:35 -0000 Hello FreeBSD-Net, does anybody remember, around year 2004, there was a software application available (either as port, or package). Unfortunately I do not recall the application name and I'm not able to find it again, although I've reviewed the Ports collection from year 2005 which I have on 3 DVDs. I do not remember if the application captured data from the network interface by itself, or used tcpdump output, that actually doesn't matter. What matters is that this app draw a picture of the selected IP packet's header, similar to the one in RFC791 at page 11, chapter "3.1. Internet Header Format". The picture drawn was minimalistic and in colors (green, yellow), and it showed the field values from the actual capture. I've ran it under TWM, and it looked close to that one, but showing captured values instead of (or along with) field names - Appreciate if anybody remembers that application by a chance and could tell its name. thank you 3des From owner-freebsd-net@freebsd.org Wed Nov 1 22:45:42 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A111E662BC for ; Wed, 1 Nov 2017 22:45:42 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id 73E741CBC for ; Wed, 1 Nov 2017 22:45:42 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 33B00156E7D7; Wed, 1 Nov 2017 15:39:15 -0700 (PDT) From: Bakul Shah To: DES <3des@inx.su> cc: freebsd-net@freebsd.org Subject: Re: IP packet header visualization software In-reply-to: Your message of "Thu, 02 Nov 2017 00:46:25 +0300." <6de334e9-8962-e43d-006d-8bc2fe4ec1ea@inx.su> References: <6de334e9-8962-e43d-006d-8bc2fe4ec1ea@inx.su> Comments: In-reply-to DES <3des@inx.su> message dated "Thu, 02 Nov 2017 00:46:25 +0300." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <72745.1509575955.1@bitblocks.com> Date: Wed, 01 Nov 2017 15:39:15 -0700 Message-Id: <20171101223930.33B00156E7D7@mail.bitblocks.com> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 01 Nov 2017 22:45:42 -0000 On Thu, 02 Nov 2017 00:46:25 +0300 DES <3des@inx.su> wrote: DES writes: > Hello FreeBSD-Net, > > does anybody remember, around year 2004, there was a software > application available (either as port, or package). Unfortunately I do > not recall the application name and I'm not able to find it again, > although I've reviewed the Ports collection from year 2005 which I have > on 3 DVDs. I do not remember if the application captured data from the > network interface by itself, or used tcpdump output, that actually > doesn't matter. What matters is that this app draw a picture of the > selected IP packet's header, similar to the one in RFC791 at page 11, > chapter "3.1. Internet Header Format". The picture drawn was > minimalistic and in colors (green, yellow), and it showed the field > values from the actual capture. I've ran it under TWM, and it looked > close to that one, but showing captured values instead of (or along > with) field names - > > Appreciate if anybody remembers that application by a chance and could > tell its name. ethereal? It later became wireshark. From owner-freebsd-net@freebsd.org Wed Nov 1 23:38:12 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BADFE66EBD for ; Wed, 1 Nov 2017 23:38:12 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B6D6C35C3 for ; Wed, 1 Nov 2017 23:38:11 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-vk0-x22b.google.com with SMTP id x65so2483491vkx.1 for ; Wed, 01 Nov 2017 16:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=qksYvEC8J3QUSS0lR6V+NItvbwz2vwLlib+VhdRguY8=; b=g7sovBaem6WKXnQpS5YYs4w50E3m4TlP28n2HIW3IhcZZPWXBm8L2Y/q+TEuDknH+Y W+Ez3lRVjhkgekBnVQTp8r8V+P16ud6VYNv3zyqNwJ4u6U5xKNP6GsUqNlfulOxKFzSX 0Xfv8o1dsY/cgOFBsoHvF6aQbgE2VZk/W+s29tYd+fuLCP+coUulcYy0rJ+Ja+/FM4MY 5XmDKcFAbEW3miiG2TPn9iMUS0YLlXv73Ia2WX8y3bf60YO4adst5Osk8gQO6vODdC2+ AXTtIN1HsYeFw9qMlQG/ghIyWiOSOaRjfFcPv628BA5PB/YgAn3SWxg/DD2haz36CXXi G5Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=qksYvEC8J3QUSS0lR6V+NItvbwz2vwLlib+VhdRguY8=; b=fl8xV7aroxUubOyChTx3W80V1ziKmS2x4HJa3UYnk+QCKso1jpfMnVEEHuHUhMe/G0 25QRGLfBkBKM383tOYKx32tfI6CzdV9oQVpjipmpqvuQSae+gJWk8HJHctvgGFlO7A4J GmQGlSJj+MnVCvSgI7PziVMJRlnJAw60jMsf5bBb/xTKLDRCEwHEFtoqfA/ZsRaWHbWn sfcXgj5RxNUNABK7zG1QR++QsMDZtz9S9Q/zURYF4WrpgHo5EqYBESO5c6pbn2NT5DH8 DNT3RW7npzmi76DwASORp+vfLxc3c5YDsn7e8tyBXsOPAjlGNuYg4X575W7n+WNSIhXf z2KQ== X-Gm-Message-State: AMCzsaWmQr34t0CaaRe+FA+BYNTLixOfJ0ifiarj0M+1NUI9/oJdE/Ne WuAIcRSCTABwxtWg9akI5qK1J6hUEoaV/NgU6a6Psw== X-Google-Smtp-Source: ABhQp+Tunxmb7++WKJhlBRo4mRgIcj+ybPjJcZgonmqu3V/JQ71t0Z+XMAgJjJHDDFIp+AuM3lLHG+r+iCrghv7NPQA= X-Received: by 10.31.210.69 with SMTP id j66mr1256804vkg.196.1509579490661; Wed, 01 Nov 2017 16:38:10 -0700 (PDT) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 10.103.85.8 with HTTP; Wed, 1 Nov 2017 16:38:10 -0700 (PDT) In-Reply-To: <6de334e9-8962-e43d-006d-8bc2fe4ec1ea@inx.su> References: <6de334e9-8962-e43d-006d-8bc2fe4ec1ea@inx.su> From: Kevin Oberman Date: Wed, 1 Nov 2017 16:38:10 -0700 X-Google-Sender-Auth: O5XaKb6J2zYtqGalH0pgGfbjNwY Message-ID: Subject: Re: IP packet header visualization software To: DES <3des@inx.su> Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 01 Nov 2017 23:38:12 -0000 On Wed, Nov 1, 2017 at 2:46 PM, DES <3des@inx.su> wrote: > Hello FreeBSD-Net, > > does anybody remember, around year 2004, there was a software application > available (either as port, or package). Unfortunately I do not recall the > application name and I'm not able to find it again, although I've reviewed > the Ports collection from year 2005 which I have on 3 DVDs. I do not > remember if the application captured data from the network interface by > itself, or used tcpdump output, that actually doesn't matter. What matters > is that this app draw a picture of the selected IP packet's header, similar > to the one in RFC791 at page 11, chapter "3.1. Internet Header Format". The > picture drawn was minimalistic and in colors (green, yellow), and it showed > the field values from the actual capture. I've ran it under TWM, and it > looked close to that one, but showing captured values instead of (or along > with) field names - > > Appreciate if anybody remembers that application by a chance and could > tell its name. > > thank you > > 3des > tcptrace? I have not used it since I retired, but I think it was similar to what you are looking for. Its output is just text. It used an external tool to implement the plots, xplot. xplot died back on gcc-3.3 and I have no idea what its current status is, but I fear it's abandoned, xpolt.org still is alive, though. From owner-freebsd-net@freebsd.org Thu Nov 2 07:09:52 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75C62E51DDA for ; Thu, 2 Nov 2017 07:09:52 +0000 (UTC) (envelope-from alex@zagrebin.ru) Received: from mail.zagrebin.ru (srv0.zagrebin.ru [IPv6:2001:470:1f15:30e::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2D59670556 for ; Thu, 2 Nov 2017 07:09:51 +0000 (UTC) (envelope-from alex@zagrebin.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zagrebin.ru ; s=mail; h=Content-Type:MIME-Version:References:In-Reply-To:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=sPDel+8wpLSXgTu4qjZ933pSsL1QuKI59311awd22+I=; b=bonSEgtyCIKoS0tpELAAoTAyFf 9Cbp0UPERjLaKI5KN/558P2955GYvNPKZUlD0T9JxtR329DcE7uGboxefl0UltFpJWcI9XYt5IdLg d2pPSGILclHVSCfqVlUez8wsu3lqVq/Y/b0XoWpghd30Zt+H+jY7NRE1pq8zdhtemst8oX8Bwz8ML dHQc0JP6CxMBYnHMKEis7RG8s+uOEuMySqXyBR/CZJy7PxpiZLERDH+XLB9Me6wBz2zTqbZrv9DXp 4mLYKpKk8d2k3/duWd3nZEGX+aphwnuV7pQevIi3qlJnr3AMKcJkhDcqLugsoSBY278URK1EsCGLA ms5qHx8A==; Received: from [2001:470:1f15:30e::2] (helo=vm2.home.zagrebin.ru) by mail.zagrebin.ru with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1eA9dM-0005Xo-7k; Thu, 02 Nov 2017 10:09:48 +0300 Date: Thu, 2 Nov 2017 10:09:47 +0300 From: Alexander Zagrebin To: freebsd-net@freebsd.org Subject: Re: Help provisioning a Samba AD in a jail on ZFS Message-ID: <20171102100947.424ce456@vm2.home.zagrebin.ru> In-Reply-To: <57dc8e1e-6e38-456d-f70d-291d6bf68bb8@netfence.it> References: <57dc8e1e-6e38-456d-f70d-291d6bf68bb8@netfence.it> X-Mailer: Claws Mail 3.15.1 (GTK+ 2.24.31; amd64-portbld-freebsd11.1) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 02 Nov 2017 07:09:52 -0000 В Wed, 1 Nov 2017 16:01:18 +0100 Andrea Venturoli пишет: It seems it's offtopic here, but I'll try to answer. To setup a new samba46-based domain controller on ZFS in jail (I'm using it with the VIMAGE) you can try following: 1. Rebuild the net/samba46 port with the attached patches (patch-librpc__idl__xattr.idl, patch-python__samba__provision____init__.py) 2. Initialize new domain with the following command (the last two parameters makes magic): samba-tool domain provision --use-rfc2307 \ --host-name= \ --realm= \ --domain= \ --adminpass= \ --option="vfs objects = acl_xattr" \ --option="acl_xattr:ignore system acls = yes" 3. After successful provisioning, edit /usr/local/etc/smb4.conf: - remove or comment out vfs objects = acl_xattr acl_xattr:ignore system acls = yes - add the following: vfs objects = zfsacl nfs4:mode = special nfs4:acedup = merge nfs4:chown = yes 4. Execute `samba-tool ntacl sysvolreset` 5. Start samba It is not ideal solution, but it seems to be working, despite there are another resolvable issues (with BIND9_DLZ and so on)... I've sent patches to the port maintainer, but have no answer. > As per subject, I'm building a new box which must host a jail running > a Samba AD, but I have trouble provisioning it. > Currently I'm trying samba44. > > I read a lot of material and I think I understand the problem: it > seems the "samba-tool provision" script is incompatible with NFSv4ACL > used by ZFS. AFAICT this issue has been raised, the Samba team has > acknowledged a patch should be made, but so far nothing happened. > > So I'm looking into workarounds: > > a) someone suggest installing samba43, provision, then upgrade to > samba44. In fact this is some path I went through a couple of times > in the past (on UFS, however). Alas samba43 is no longer there. > > b) I think I might get around this by provisioning with the > deprecated NTVFS, then switch to S3FS. > Unfortunately samba44 does not build NTVFS anymore, unless the > DEVELOPER option is used; but if the DEVELOPER option is used > compilation (on Poudriere) fails with: > > ../source4/lib/socket/socket_ip.c:864:12: error: comparison of > > array 'addr.__u6_addr.__u6_addr8' equal to a null pointer is always > > false [-Werror,-Wtautological-pointer-compare] if (addr.s6_addr == > > 0) { ~~~~~^~~~~~~ ~ /usr/include/netinet6/in6.h:103:29: note: > > expanded from macro 's6_addr' #define s6_addr __u6_addr.__u6_addr8 > > ^ > > 1 error generated. > > c) I tried creating a ZVOL, formatting it with UFS, mounting it with > ACLs inside the jail, but still provisioning says I have no ACL > support. > > d) I know samba46 is incompatible with jails (at least as AD DC), but > didn't try samba45. AFAICT, however, nothing should have improved WRT > to my problem. > > So, after spending a couple of days on this and before spending > another week trying every path, I tought I'd ask... > > Should I temporarily revive samba43? > Can samba44 with NTVFS compilation error be fixed? > Should I try samba45 or is it just a waste of time? > Would creating a jail on another (UFS) box and then moving > /var/db/samba4 and smb4.conf here work? > > I'm open to any other suggestion as long as the objective (AD in a > jail on ZFS) is met in the end. -- Alexander Zagrebin From owner-freebsd-net@freebsd.org Thu Nov 2 07:19:41 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 103DFE52252; Thu, 2 Nov 2017 07:19:41 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 82E99709F0; Thu, 2 Nov 2017 07:19:39 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id vA27JPvi000321 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 2 Nov 2017 08:19:26 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: lev@FreeBSD.org Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTP id vA27JMQS040763; Thu, 2 Nov 2017 14:19:22 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Low default setting of UDBHASHSIZE leads to unresponsive system To: lev@FreeBSD.org, freebsd-net@freebsd.org, freebsd-stable@freebsd.org References: From: Eugene Grosbein Message-ID: <59FAC6FA.3070804@grosbein.net> Date: Thu, 2 Nov 2017 14:19:22 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, score=5.5 required=5.0 tests=BAYES_00, DATE_IN_FUTURE_96_Q, LOCAL_FROM,RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * 3.3 DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: date * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-Spam-Flag: YES X-Spam-Level: ***** X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 02 Nov 2017 07:19:41 -0000 On 01.11.2017 22:35, Lev Serebryakov wrote: > > Now 11-STABLE (and 12-CURRENT too) have this: > > sys/netinet/udp_usrreq.c:#define UDBHASHSIZE 128 > > Looks like such low value could lead to 100% consumption of CPU by > interrupt threads (igb queues in my case) on heavy incoming UDP traffic > (torrents with uTP in my case). > > My system (E3-1220v3 with I210 NICs) becomes completely unresponsive > (nut complains about lost connection to UPS, ssh to system times out, > etc) when system downloads torrent with many uTP (UDP) peers. Four igb0 > queues consume 100% CPU each in this scenario. > > Total traffic could be very low like 500KiB/s (yes, 500KiB/s, not > MiB/s!), I don't speak about 1Gbit/s or even 100Mbit/s here! > > Rebuilding kernel with UDBHASHSIZE=16384 seems to help. > > Why is this value so low and why I need to patch sources to change it? > Many such settings are changeable via sysctl and/or tunables, but this > one looks hardcoded. You should fill a PR. Attach these performance numbers you got. If possible, attach a patch introducing new loader tunnable, that should be easy. Keep me CC'd. From owner-freebsd-net@freebsd.org Thu Nov 2 12:28:16 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F456E58964 for ; Thu, 2 Nov 2017 12:28:16 +0000 (UTC) (envelope-from marko.cupac@mimar.rs) Received: from mail.mimar.rs (tazar.mimar.rs [193.53.106.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A8777CFBC for ; Thu, 2 Nov 2017 12:28:15 +0000 (UTC) (envelope-from marko.cupac@mimar.rs) Received: from tazar.mimar.rs (localhost [127.0.2.132]) by mail.mimar.rs (Postfix) with ESMTP id DD5AB625A2A5 for ; Thu, 2 Nov 2017 13:19:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mimar.rs; h= content-transfer-encoding:content-type:content-type:mime-version :x-mailer:organization:references:in-reply-to:message-id:subject :subject:from:from:date:date:received:received; s=mimar-0901; t= 1509625172; x=1511439573; bh=AgMhQUGjBL2L4SfRWYVzigCntBSCliPrSEw DrQrYsiI=; b=2kJwx+cBvRIbZNqWv2nCdp74+3sUb687zWAjwJ4NVSMxEuvIBh0 Lk0jaZA6TKFNe35A8NRcogixuvRkL2sgQ6qjvWfFud+hpOIGmkpsfAFNlQ7oQ/YE 1v+G6s0Q7sULq5wjOP8mZjNuw9GIoX5kPAF3i3147wpC64G86PoNRDH8= X-Virus-Scanned: amavisd-new at mimar.rs Received: from mail.mimar.rs ([127.0.2.132]) by tazar.mimar.rs (amavis.mimar.rs [127.0.2.132]) (amavisd-new, port 10026) with LMTP id lIQoqjxwpIvI for ; Thu, 2 Nov 2017 13:19:32 +0100 (CET) Received: from efreet-freebsd.kappastar.com (nat-nat.kappastar.com [193.53.106.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: marko.cupac) by mail.mimar.rs (Postfix) with ESMTPSA id C73FA625A2A4 for ; Thu, 2 Nov 2017 13:19:32 +0100 (CET) Date: Thu, 2 Nov 2017 13:19:31 +0100 From: Marko =?UTF-8?B?Q3VwYcSH?= To: freebsd-net@freebsd.org Subject: Re: VLANing between jails not segmenting traffic Message-ID: <20171102131931.452f1106@efreet-freebsd.kappastar.com> In-Reply-To: <2A44422B-31A9-4ADC-8FCE-D1F8BC03623C@freebsd.org> References: <4d50ef1e-1cc2-aca2-d390-313ef824d524@gmail.com> <59F79902.40408@grosbein.net> <2A44422B-31A9-4ADC-8FCE-D1F8BC03623C@freebsd.org> Organization: Mimar X-Mailer: Claws Mail 3.15.1 (GTK+ 2.24.31; amd64-portbld-freebsd11.1) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 02 Nov 2017 12:28:16 -0000 On Mon, 30 Oct 2017 22:46:35 +0100 Michael Gmelin wrote: > You can use fibs with net.add_addr_allfibs=3D0 to get separate routing > tables (comes with its own set of complications though). I hoped to go this way, but the fact that host (in fib0) replies to icmp requests destined to jail with raw_sockets disabled (in fib 1) via host's default gateway, making really wierd routing situation. Had to go back to separate physical hosts for now. Will check VIMAGE. --=20 Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupa=C4=87 https://www.mimar.rs/ From owner-freebsd-net@freebsd.org Thu Nov 2 14:49:40 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DB6FCE5BC5E for ; Thu, 2 Nov 2017 14:49:40 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 4A09D81537 for ; Thu, 2 Nov 2017 14:49:39 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: (qmail 65989 invoked by uid 89); 2 Nov 2017 14:42:56 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@194.97.158.70) by mail.grem.de with ESMTPA; 2 Nov 2017 14:42:56 -0000 Date: Thu, 2 Nov 2017 15:42:55 +0100 From: Michael Gmelin To: Marko =?UTF-8?B?Q3VwYcSH?= Cc: freebsd-net@freebsd.org Subject: Re: VLANing between jails not segmenting traffic Message-ID: <20171102154255.12ca7e4d@bsd64.grem.de> In-Reply-To: <20171102131931.452f1106@efreet-freebsd.kappastar.com> References: <4d50ef1e-1cc2-aca2-d390-313ef824d524@gmail.com> <59F79902.40408@grosbein.net> <2A44422B-31A9-4ADC-8FCE-D1F8BC03623C@freebsd.org> <20171102131931.452f1106@efreet-freebsd.kappastar.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd10.2) X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 02 Nov 2017 14:49:41 -0000 On Thu, 2 Nov 2017 13:19:31 +0100 Marko Cupa=C4=87 wrote: > On Mon, 30 Oct 2017 22:46:35 +0100 > Michael Gmelin wrote: >=20 > > You can use fibs with net.add_addr_allfibs=3D0 to get separate routing > > tables (comes with its own set of complications though). =20 >=20 > I hoped to go this way, but the fact that host (in fib0) replies to > icmp requests destined to jail with raw_sockets disabled (in fib 1) > via host's default gateway, making really wierd routing situation. Shouldn't you be able to fix this using a pf pass rule with rtable? Maybe you can share more of your setup, quite curious. -m >=20 > Had to go back to separate physical hosts for now. Will check VIMAGE. --=20 Michael Gmelin From owner-freebsd-net@freebsd.org Thu Nov 2 15:21:12 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9BC7DE5C6C5 for ; Thu, 2 Nov 2017 15:21:12 +0000 (UTC) (envelope-from marko.cupac@mimar.rs) Received: from mail.mimar.rs (tazar.mimar.rs [193.53.106.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F6A88246D; Thu, 2 Nov 2017 15:21:11 +0000 (UTC) (envelope-from marko.cupac@mimar.rs) Received: from tazar.mimar.rs (localhost [127.0.2.132]) by mail.mimar.rs (Postfix) with ESMTP id 626B7625A288; Thu, 2 Nov 2017 16:21:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mimar.rs; h= content-transfer-encoding:content-type:content-type:mime-version :x-mailer:organization:references:in-reply-to:message-id:subject :subject:from:from:date:date:received:received; s=mimar-0901; t= 1509636062; x=1511450463; bh=5LWaPl1cw/diAZcIEt2JOfzzNBc5nwG5+jt IRJGpulk=; b=FfxUTZ2vv6pd9BS+c9dPJLmeqRc3jbBESGqDbZ73kpAyiJDm5Gj pzKOEwKMq18y27/GFKsPc+Di42qbHKxsW8J8k62shahmpmPD2pdavv3ae64X7HOv Wr+GLaoYy8YOJpkigXLr/yr0+19QaDbjwuhfYhT86Y8eC71kuzuDoEpY= X-Virus-Scanned: amavisd-new at mimar.rs Received: from mail.mimar.rs ([127.0.2.132]) by tazar.mimar.rs (amavis.mimar.rs [127.0.2.132]) (amavisd-new, port 10026) with LMTP id ErLUKflSl3Nc; Thu, 2 Nov 2017 16:21:02 +0100 (CET) Received: from efreet-freebsd.kappastar.com (nat-nat.kappastar.com [193.53.106.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: marko.cupac) by mail.mimar.rs (Postfix) with ESMTPSA id 66E69625A286; Thu, 2 Nov 2017 16:21:02 +0100 (CET) Date: Thu, 2 Nov 2017 16:21:01 +0100 From: Marko =?UTF-8?B?Q3VwYcSH?= To: Michael Gmelin Cc: freebsd-net@freebsd.org Subject: Re: VLANing between jails not segmenting traffic Message-ID: <20171102162101.4e334dfd@efreet-freebsd.kappastar.com> In-Reply-To: <20171102154255.12ca7e4d@bsd64.grem.de> References: <4d50ef1e-1cc2-aca2-d390-313ef824d524@gmail.com> <59F79902.40408@grosbein.net> <2A44422B-31A9-4ADC-8FCE-D1F8BC03623C@freebsd.org> <20171102131931.452f1106@efreet-freebsd.kappastar.com> <20171102154255.12ca7e4d@bsd64.grem.de> Organization: Mimar X-Mailer: Claws Mail 3.15.1 (GTK+ 2.24.31; amd64-portbld-freebsd11.1) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 02 Nov 2017 15:21:12 -0000 On Thu, 2 Nov 2017 15:42:55 +0100 Michael Gmelin wrote: > On Thu, 2 Nov 2017 13:19:31 +0100 > Marko Cupa=C4=87 wrote: >=20 > > On Mon, 30 Oct 2017 22:46:35 +0100 > > Michael Gmelin wrote: > > =20 > > > You can use fibs with net.add_addr_allfibs=3D0 to get separate > > > routing tables (comes with its own set of complications > > > though). =20 > >=20 > > I hoped to go this way, but the fact that host (in fib0) replies to > > icmp requests destined to jail with raw_sockets disabled (in fib 1) > > via host's default gateway, making really wierd routing situation. =20 >=20 > Shouldn't you be able to fix this using a pf pass rule with rtable? I am sure it could be fixed as you said, but I don't want to introduce more complexity with PF. > Maybe you can share more of your setup, quite curious. I wrote about that here on the list, and on -jail as well (both are the same): [https://lists.freebsd.org/pipermail/freebsd-jail/2017-September/003442.htm= l] [https://lists.freebsd.org/pipermail/freebsd-net/2017-October/049037.html] I also got off-list reply from a guy who says this behaviour was introduced in 11.X, and not present in 10.X. Didn't have the time to test on 10.X. Regards, --=20 Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupa=C4=87 https://www.mimar.rs/ From owner-freebsd-net@freebsd.org Thu Nov 2 15:53:43 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F3C49E5D380 for ; Thu, 2 Nov 2017 15:53:42 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 5C62D8395A for ; Thu, 2 Nov 2017 15:53:41 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: (qmail 66708 invoked by uid 89); 2 Nov 2017 15:46:59 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@194.97.158.70) by mail.grem.de with ESMTPA; 2 Nov 2017 15:46:59 -0000 Date: Thu, 2 Nov 2017 16:46:57 +0100 From: Michael Gmelin To: Marko =?UTF-8?B?Q3VwYcSH?= Cc: freebsd-net@freebsd.org Subject: Re: VLANing between jails not segmenting traffic Message-ID: <20171102164657.59074b14@bsd64.grem.de> In-Reply-To: <20171102162101.4e334dfd@efreet-freebsd.kappastar.com> References: <4d50ef1e-1cc2-aca2-d390-313ef824d524@gmail.com> <59F79902.40408@grosbein.net> <2A44422B-31A9-4ADC-8FCE-D1F8BC03623C@freebsd.org> <20171102131931.452f1106@efreet-freebsd.kappastar.com> <20171102154255.12ca7e4d@bsd64.grem.de> <20171102162101.4e334dfd@efreet-freebsd.kappastar.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd10.2) X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 02 Nov 2017 15:53:43 -0000 On Thu, 2 Nov 2017 16:21:01 +0100 Marko Cupa=C4=87 wrote: > On Thu, 2 Nov 2017 15:42:55 +0100 > Michael Gmelin wrote: >=20 > > On Thu, 2 Nov 2017 13:19:31 +0100 > > Marko Cupa=C4=87 wrote: > > =20 > > > On Mon, 30 Oct 2017 22:46:35 +0100 > > > Michael Gmelin wrote: > > > =20 > > > > You can use fibs with net.add_addr_allfibs=3D0 to get separate > > > > routing tables (comes with its own set of complications > > > > though). =20 > > >=20 > > > I hoped to go this way, but the fact that host (in fib0) replies > > > to icmp requests destined to jail with raw_sockets disabled (in > > > fib 1) via host's default gateway, making really wierd routing > > > situation. =20 > >=20 > > Shouldn't you be able to fix this using a pf pass rule with > > rtable? =20 >=20 > I am sure it could be fixed as you said, but I don't want to introduce > more complexity with PF. It would be something simple like "pass proto icmp to y rtable n" If you're not already using pf you obviously don't want to introduce it only to solve this problem. >=20 > > Maybe you can share more of your setup, quite curious. =20 >=20 > I wrote about that here on the list, and on -jail as well (both are > the same): > [https://lists.freebsd.org/pipermail/freebsd-jail/2017-September/003442.h= tml] > [https://lists.freebsd.org/pipermail/freebsd-net/2017-October/049037.html] >=20 > I also got off-list reply from a guy who says this behaviour was > introduced in 11.X, and not present in 10.X. Didn't have the time to > test on 10.X. I only use 10.x for complex networking in production right now :/ -m >=20 > Regards, --=20 Michael Gmelin From owner-freebsd-net@freebsd.org Thu Nov 2 17:22:16 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D70E8E5EF95 for ; Thu, 2 Nov 2017 17:22:16 +0000 (UTC) (envelope-from SRS0=dMqAzd=CA=codenetworks.net=sm@eigbox.net) Received: from bosmailout04.eigbox.net (bosmailout04.eigbox.net [66.96.184.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A648C1D3E for ; Thu, 2 Nov 2017 17:22:16 +0000 (UTC) (envelope-from SRS0=dMqAzd=CA=codenetworks.net=sm@eigbox.net) Received: from bosmailscan14.eigbox.net ([10.20.15.14]) by bosmailout04.eigbox.net with esmtp (Exim) id 1eAIca-0007Jk-Jy for freebsd-net@freebsd.org; Thu, 02 Nov 2017 12:45:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codenetworks.net; s=dkim; h=Sender:Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:To:Subject:From:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=a8tPc0G2B3eezvohp4hBs5hDpOwaq+1YatdVlafc/fs=; b=hUj49IiSIi72DPO+3YZmi9XVEF ZepIFeLJ27e2Budpe4FbDjA5IsdSoslN9lY7LgRXeQtIGafNzDg+lj/ReHgP0456e+AH0ftEZXFhZ IicrSI9vUyrQxf4YOpMp6KGtiZroJhAHI+cFStMlKTlxUSTVZUiRp+c6oaG24nT8T0nOK2aMNZraQ cc5jJ3PCdfM0YOUD1W6ixESTB0o/ibbF9nvc6034XzuWumLXgsTD4MlDLrjVWWuiNKM08hvsZZzqS /LWLeOBpL024i8VjvTRW3FRQstvHFXTyySbueTpoR4yvwaqwbmdF+8aeV1z8QZGYDsD6BpZd/7lDR 5s6IhZsA==; Received: from [10.115.3.31] (helo=bosimpout11) by bosmailscan14.eigbox.net with esmtp (Exim) id 1eAIca-0002cO-EI for freebsd-net@freebsd.org; Thu, 02 Nov 2017 12:45:36 -0400 Received: from bosauthsmtp08.yourhostingaccount.com ([10.20.18.8]) by bosimpout11 with id V4lZ1w0050ASroS014lcdW; Thu, 02 Nov 2017 12:45:36 -0400 X-Authority-Analysis: v=2.2 cv=RdbgMxlv c=1 sm=1 tr=0 a=BF10AaGwQl41phDg7WSPyA==:117 a=ecHzJlqNrjqemkbW8Bp8sw==:17 a=IkcTkHD0fZMA:10 a=sC3jslCIGhcA:10 a=5sCBbic07u0A:10 a=B3gGe52qEeb0hB1gp2oA:9 a=QEXdDO2ut3YA:10 Received: from host31-49-228-163.range31-49.btcentralplus.com ([31.49.228.163]:31149 helo=[192.168.100.100]) by bosauthsmtp08.eigbox.net with esmtpa (Exim) id 1eAIcX-0008MJ-12 for freebsd-net@freebsd.org; Thu, 02 Nov 2017 12:45:33 -0400 From: Santiago Martinez Subject: FreeBSD 11.1 vmx + netmap queues To: "freebsd-net@freebsd.org" Message-ID: <2bd87cdb-9ef7-387a-ba8a-cc7c90702eea@codenetworks.net> Date: Thu, 2 Nov 2017 16:45:31 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-EN-UserInfo: d3bdfab0736480cedf04ed92aaea2ef5:931c98230c6409dcc37fa7e93b490c27 X-EN-AuthUser: sm@codenetworks.net Sender: Santiago Martinez X-EN-OrigIP: 31.49.228.163 X-EN-OrigHost: host31-49-228-163.range31-49.btcentralplus.com X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 02 Nov 2017 17:22:17 -0000 Hi list, hope you guys are doing well. I have a basic question. Do you know if multiple TX queues are supported  for vmx + netmap ? Basically I'm using pkt-gen to generate bulk traffic @10Gbps and its OK with packet size >~1000b. For small packets I should use multiple cores/processes to be able to generate the required pps, but pkg-gen complain that I have only one queue. I tried adding multiple queues for vmx on loader.conf (can verify with sysctl) but netmap still complaining there is only one queue. sysctl -a | grep vmx.1: dev.vmx.1.mbuf_load_failed: 0 dev.vmx.1.mgetcl_failed: 0 dev.vmx.1.defrag_failed: 0 dev.vmx.1.defragged: 0 dev.vmx.1.nrxqueues: 8 dev.vmx.1.ntxqueues: 4 dev.vmx.1.max_nrxqueues: 8 dev.vmx.1.max_ntxqueues: 4 dev.vmx.1.%parent: pci4 dev.vmx.1.%pnpinfo: vendor=0x15ad device=0x07b0 subvendor=0x15ad subdevice=0x07b0 class=0x020000 dev.vmx.1.%location: slot=0 function=0 dbsf=pci0:11:0:0 handle=\_SB_.PCI0.PE50.S1F0 dev.vmx.1.%driver: vmx dev.vmx.1.%desc: VMware VMXNET3 Ethernet Adapter pkg-gen still saying one queue for vmx: Sending on netmap:vmx1: 1 queues, 2 threads and 4 cpus. Thanks in advance. Santiago From owner-freebsd-net@freebsd.org Thu Nov 2 19:35:46 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B34DE61A22 for ; Thu, 2 Nov 2017 19:35:46 +0000 (UTC) (envelope-from 3des@inx.su) Received: from relay12.nicmail.ru (relay12.nicmail.ru [195.208.5.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB936667C6 for ; Thu, 2 Nov 2017 19:35:44 +0000 (UTC) (envelope-from 3des@inx.su) Received: from [109.70.25.227] (port=58478 helo=[192.168.35.23]) by f06.mail.nic.ru with esmtp (Exim 5.55) (envelope-from <3des@inx.su>) id 1eALHD-000AJH-0h; Thu, 02 Nov 2017 22:35:43 +0300 Received: from [37.190.110.16] (account 3des@inx.su HELO [192.168.35.23]) by proxy05.mail.nic.ru (Exim 5.55) with id 1eALHA-0000LU-6X; Thu, 02 Nov 2017 22:35:40 +0300 Subject: Re: IP packet header visualization software To: Kevin Oberman Cc: "freebsd-net@freebsd.org" References: <6de334e9-8962-e43d-006d-8bc2fe4ec1ea@inx.su> From: DES <3des@inx.su> Message-ID: <9ba277c4-d0b2-3eb7-2fcd-680eb47e2577@inx.su> Date: Thu, 2 Nov 2017 22:35:41 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 02 Nov 2017 19:35:46 -0000 thank you for the response Kevin and Bakul, but neither tcptrace nor ethereal/wireshark is what I'm looking for. As I said, the application I was using was drawing single IP packet header similar to what is presented in RFC791 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |Version|  IHL  |Type of Service|          Total Length         | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |         Identification        |Flags|      Fragment Offset    | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |  Time to Live |    Protocol   |         Header Checksum       | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |                       Source Address                          | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |                    Destination Address                        | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |                    Options                    | Padding    | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ But a) graphically with colors, b) with actual packet/header data from the captured IP packet. Actual result looked similar to this picture - https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.networkcomm/figures/comma35.jpg thank you 3des On 02.11.2017 02:38, Kevin Oberman wrote: > On Wed, Nov 1, 2017 at 2:46 PM, DES <3des@inx.su > > wrote: > > Hello FreeBSD-Net, > > does anybody remember, around year 2004, there was a software > application available (either as port, or package). Unfortunately > I do not recall the application name and I'm not able to find it > again, although I've reviewed the Ports collection from year 2005 > which I have on 3 DVDs. I do not remember if the application > captured data from the network interface by itself, or used > tcpdump output, that actually doesn't matter. What matters is that > this app draw a picture of the selected IP packet's header, > similar to the one in RFC791 at page 11, chapter "3.1. Internet > Header Format". The picture drawn was minimalistic and in colors > (green, yellow), and it showed the field values from the actual > capture. I've ran it under TWM, and it looked close to that one, > but showing captured values instead of (or along with) field names - > > Appreciate if anybody remembers that application by a chance and > could tell its name. > > thank you > > 3des > > > tcptrace? I have not used it since I retired, but I think it was > similar to what you are looking for. Its output is just text. It used > an external tool to implement the plots, xplot. xplot died back on > gcc-3.3 and I have no idea what its current status is, but I fear it's > abandoned, xpolt.org still is alive, though. > From owner-freebsd-net@freebsd.org Thu Nov 2 20:38:45 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96BE6E629C3 for ; Thu, 2 Nov 2017 20:38:45 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5EE3068734 for ; Thu, 2 Nov 2017 20:38:45 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: by mail-io0-x236.google.com with SMTP id d66so1834395ioe.5 for ; Thu, 02 Nov 2017 13:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9HpGWLHgn6bMdnBeA6Dljrq2ue53uSiECHwcJWQa1Pg=; b=u5dllRBicLQ+aWCst/LRNBC8xkiuyKNvLWGoiPtPW8Qibn7fRvwlCacjx5eKrhYcUg pjl6JJC8SLWMRcRlDsEsACZvc1J1Q4s4PNrO+dcZ0hpBXPoxFooweqgi60k0cYggqHEy fqQP9rrD8gjzO1PUPisAB/dVuAWdDDXW4+mTa4kt1OIwRNlODUNA9x/o+mTggkqsmTIX qZPgpjduJV8iyrtPvCXJOkKyHsJZVD5cbuHt20BYhcaO/UHmkNLu5S17qUV/B1kKmUtY ySxx4z1iGqhloO9gjLl4TZURKwU24vP402DZvMIpJfM53dgid1x7s9zPAjINJ8hCLZa9 34oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9HpGWLHgn6bMdnBeA6Dljrq2ue53uSiECHwcJWQa1Pg=; b=Z5e/l9d00HUtfj5cxKgmg51XmCCpyvTTdNYq9Aq+QgcwHaYIyMxYXTyOSdkcL+p7oC yjpAPLUDlVy4uc/mMba0OWyBNftyprOXEmeURkSi8hOuKpSQ3eSIU8icQlhgDD7CxAEA Tm3mdaHozebwGCBwCI29yyY4JLVSjNWsD+K++lbZiKWUw1LSuTfCJgQLPpn0pAv/2XgX OKuszh8KPsbf5HaJVG1+12HRO+shdCL9LXlYhbPOUhN76W4FfJ1cKEHj44cVRLUgEcUp TDcgO3y6CS0XIJgmYyGStBPfSLtteLMLsOWEA2PRQaoF8Zx6HEYJHVvgw6JAAaVqB7sl t6IA== X-Gm-Message-State: AMCzsaXeJJQ3qjtbD3fiTgCLtaFioqxPba+66epx2gVpYuUI9PIlNhx+ /um22Fg0HUZTgX9DuKXBZJ0t+eZS4K7tSjf+93k= X-Google-Smtp-Source: ABhQp+TqSF76wmXlSx3NLrkcdPb1Go/AhEdQDL2bByvZmGo8YsQ0dRlKRwWFGCpf6wXnnlGZVTsDcnjE1PlT+BGDScw= X-Received: by 10.36.36.9 with SMTP id f9mr4300456ita.11.1509655124619; Thu, 02 Nov 2017 13:38:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.176.201 with HTTP; Thu, 2 Nov 2017 13:38:43 -0700 (PDT) In-Reply-To: <9ba277c4-d0b2-3eb7-2fcd-680eb47e2577@inx.su> References: <6de334e9-8962-e43d-006d-8bc2fe4ec1ea@inx.su> <9ba277c4-d0b2-3eb7-2fcd-680eb47e2577@inx.su> From: Adam Vande More Date: Thu, 2 Nov 2017 15:38:43 -0500 Message-ID: Subject: Re: IP packet header visualization software To: DES <3des@inx.su> Cc: Kevin Oberman , "freebsd-net@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 02 Nov 2017 20:38:45 -0000 On Thu, Nov 2, 2017 at 2:35 PM, DES <3des@inx.su> wrote: > thank you for the response Kevin and Bakul, > > but neither tcptrace nor ethereal/wireshark is what I'm looking for. As I > said, the application I was using was drawing single IP packet header > similar to what is presented in RFC791 - > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Version| IHL |Type of Service| Total Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Identification |Flags| Fragment Offset | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Time to Live | Protocol | Header Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Destination Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Options | Padding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > But a) graphically with colors, b) with actual packet/header data from the > captured IP packet. > > Actual result looked similar to this picture - > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/co > m.ibm.aix.networkcomm/figures/comma35.jpg > > thank you > 3des > I believe the application you are looking may be called "protocol". -- Adam From owner-freebsd-net@freebsd.org Thu Nov 2 21:31:07 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A42D6E63687 for ; Thu, 2 Nov 2017 21:31:07 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 726116A79E for ; Thu, 2 Nov 2017 21:31:07 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-io0-x22b.google.com with SMTP id b186so2086122iof.8 for ; Thu, 02 Nov 2017 14:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3kzOiETfv9eVjLm/fpQcYQbr57XGxwlC5sGoefpdyF0=; b=ReRrWEaqj93IO4+CjWhljgO0nR83Mv4jtEn2DetGlWkP7EpRFlb1GCcaP5bHslWB1T FH7yzTJpnhlm9lNIcI2d9epcYnEA1E0/VCaWNKK0tUyyP840sj/6pPxKeLbXDFmUbGiM bJyEudRpevJrAuMVm4Pzd1bNoMWTT3JdSMSUX+2Bxo4qffErE5mlHCUHzb9xx4zoLdgj MqY0R9taYR33TDOCDebFIUDYMKs2gcFT1OwodmtvOHrLUu56HdZ0/TOuIrZylsGoS3YY x+/3X1mbg8jxSY2KKNvqOKZJVwMUsJtBk5AODiI8f5MnReLE4yivNgq6ybij4VsKub4d XVQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3kzOiETfv9eVjLm/fpQcYQbr57XGxwlC5sGoefpdyF0=; b=N/fEbXyjL8LmgV6hxlZaHgHWT7uJlAPvk0nmGVB5LdNCXx1ohnvpJVNjYPRzTufGOZ knsPDWcGiRWESg8K01E8iDw0sMu62YwTu9iZisHH6NuzF6uxoRAPZf3axN10RsDdHSJz a8RqzMoM5zAOc0b30undQflJSFd2XVwobIy4fceMPdqVI93EXZ8/cfHx0Q+59riYWqcA cBuS9aYH1VVcy0sux7+C5NSb+73wX2pXz++/yslKhAzX8DR+PwZBwUBjA+B0FWjL+2bN A0UBBGZuKQMRc+/4bks4V1c4gOXQb3h/rOe3yC2aNcwK9POUIEM9gisZwXMtnd0K3OC6 Hqpw== X-Gm-Message-State: AJaThX7sXVbWZednJ/bgTA59/dMkn2RTQdZnHWyFkNywstsPyvIOd+ON lnCMfQkF29wKO+U+ci9J9pPs5/HDVfJG5l9W450= X-Google-Smtp-Source: ABhQp+RFD9CCu7setNaW8k372x4FFxlAor9ohaL8o+rs5ol1SmucsS3LiiPXdL3/ESfJKOV1Pmh58UvAlZijkfpMw4A= X-Received: by 10.107.81.21 with SMTP id f21mr6237271iob.63.1509658266693; Thu, 02 Nov 2017 14:31:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.176.143 with HTTP; Thu, 2 Nov 2017 14:31:05 -0700 (PDT) Received: by 10.2.176.143 with HTTP; Thu, 2 Nov 2017 14:31:05 -0700 (PDT) In-Reply-To: <2bd87cdb-9ef7-387a-ba8a-cc7c90702eea@codenetworks.net> References: <2bd87cdb-9ef7-387a-ba8a-cc7c90702eea@codenetworks.net> From: Vincenzo Maffione Date: Thu, 2 Nov 2017 22:31:05 +0100 Message-ID: Subject: Re: FreeBSD 11.1 vmx + netmap queues To: Santiago Martinez Cc: FreeBSD Net Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 02 Nov 2017 21:31:07 -0000 Hi, With vmx driver netmap will use the emulated netmap adapter. On freebsd netmap still does not have a way to see how many rings an interface has. So by default will assume 1 tx/rx rings couple for emulated adapter. You can however change this by sysctl dev.netmap.generic_rings. Cheers, Vincenzo Il 2 nov 2017 6:22 PM, "Santiago Martinez" ha scritto: > Hi list, hope you guys are doing well. > > I have a basic question. Do you know if multiple TX queues are > supported for vmx + netmap ? > > Basically I'm using pkt-gen to generate bulk traffic @10Gbps and its OK > with packet size >~1000b. > > For small packets I should use multiple cores/processes to be able to > generate the required pps, but pkg-gen complain that I have only one queue. > > I tried adding multiple queues for vmx on loader.conf (can verify with > sysctl) but netmap still complaining there is only one queue. > > sysctl -a | grep vmx.1: > dev.vmx.1.mbuf_load_failed: 0 > dev.vmx.1.mgetcl_failed: 0 > dev.vmx.1.defrag_failed: 0 > dev.vmx.1.defragged: 0 > dev.vmx.1.nrxqueues: 8 > dev.vmx.1.ntxqueues: 4 > dev.vmx.1.max_nrxqueues: 8 > dev.vmx.1.max_ntxqueues: 4 > dev.vmx.1.%parent: pci4 > dev.vmx.1.%pnpinfo: vendor=0x15ad device=0x07b0 subvendor=0x15ad > subdevice=0x07b0 class=0x020000 > dev.vmx.1.%location: slot=0 function=0 dbsf=pci0:11:0:0 > handle=\_SB_.PCI0.PE50.S1F0 > dev.vmx.1.%driver: vmx > dev.vmx.1.%desc: VMware VMXNET3 Ethernet Adapter > > pkg-gen still saying one queue for vmx: > > Sending on netmap:vmx1: 1 queues, 2 threads and 4 cpus. > > > Thanks in advance. > > Santiago > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://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 Nov 3 10:31:01 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0F7AE4E545 for ; Fri, 3 Nov 2017 10:31:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AF4DB838B0 for ; Fri, 3 Nov 2017 10:31:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id vA3AV1l6077378 for ; Fri, 3 Nov 2017 10:31:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 220078] [patch] [panic] [ipfw] repeatable kernel panic due to unlocked INADDR_TO_IFP usage Date: Fri, 03 Nov 2017 10:31:01 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: eugen@freebsd.org X-Bugzilla-Flags: mfc-stable11+ X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 03 Nov 2017 10:31:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220078 --- Comment #21 from Eugene Grosbein --- Created attachment 187688 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D187688&action= =3Dedit stable/10: lock access to INADDR_HASH in the ip_input() Fix for ip_input() adjusted to stable/10 code base. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Fri Nov 3 10:35:57 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3CCBDE4E935 for ; Fri, 3 Nov 2017 10:35:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2A73F83CC5 for ; Fri, 3 Nov 2017 10:35:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id vA3AZvg0092784 for ; Fri, 3 Nov 2017 10:35:57 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 220078] [patch] [panic] [ipfw] repeatable kernel panic due to unlocked INADDR_TO_IFP usage Date: Fri, 03 Nov 2017 10:35:57 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: eugen@freebsd.org X-Bugzilla-Flags: mfc-stable11+ X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 03 Nov 2017 10:35:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220078 --- Comment #22 from Eugene Grosbein --- Created attachment 187689 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D187689&action= =3Dedit stable/10: lock access to INADDR_TO_IFP in the in_mcast.c Fix for in_mcast.c adjusted to stable/10 code base. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Fri Nov 3 12:03:18 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E981DE50D41 for ; Fri, 3 Nov 2017 12:03:18 +0000 (UTC) (envelope-from SRS0=dVqOsD=CB=ssbglimited.co.uk=unix@eigbox.net) Received: from bosmailout07.eigbox.net (bosmailout07.eigbox.net [66.96.184.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AEBAB2CB8 for ; Fri, 3 Nov 2017 12:03:18 +0000 (UTC) (envelope-from SRS0=dVqOsD=CB=ssbglimited.co.uk=unix@eigbox.net) Received: from bosmailscan04.eigbox.net ([10.20.15.4]) by bosmailout07.eigbox.net with esmtp (Exim) id 1eAaDc-0000p6-LC for freebsd-net@freebsd.org; Fri, 03 Nov 2017 07:33:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ssbglimited.co.uk; s=dkim; h=Sender:Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=hVcZ6y5+a+czy9CipDvMYVDltrr8888iZDmgLJEks8c=; b=Bmk9o2d+TfNQWuN+8VBMth3UaT CaDM6T9Viy+1pytW9peJ9ewswdOz2sOC1sV22E7qzomcS/PxI7YyoGrWyWgqqbWaHqkAcdtzUmiJE VKdULj8HMP6waxG+Z5g07ViH/7mbUQXmEMkMAmCjh/koqfpiAR5sWMHAi+qL6Uu9eZvMMcj6QXIvv JdXPO0nNcNSfVEQInKqwDXMJ9p4/Sbt34vkxFbVXFmynu+WsmgOiDvocSjHko+asTxqB9TEeqSaTd wJkCfh4uPx61CKiszygsWUaUWrD+73/5EarKxIZkpQwLXjA3exXA1gPXlAiXjIXceSmh2h/7NPr4P JhGyxjDQ==; Received: from [10.115.3.33] (helo=bosimpout13) by bosmailscan04.eigbox.net with esmtp (Exim) id 1eAaDc-0007OU-Hc for freebsd-net@freebsd.org; Fri, 03 Nov 2017 07:33:00 -0400 Received: from bosauthsmtp08.yourhostingaccount.com ([10.20.18.8]) by bosimpout13 with id VPYx1w0050ASroS01PZ0EK; Fri, 03 Nov 2017 07:33:00 -0400 X-Authority-Analysis: v=2.2 cv=bKFmGL2Z c=1 sm=1 tr=0 a=BF10AaGwQl41phDg7WSPyA==:117 a=ecHzJlqNrjqemkbW8Bp8sw==:17 a=IkcTkHD0fZMA:10 a=sC3jslCIGhcA:10 a=5sCBbic07u0A:10 a=jlvWEfeLAAAA:8 a=6I5d2MoRAAAA:8 a=lz46LIayZNdbRTofgEEA:9 a=QEXdDO2ut3YA:10 a=BUduvz6nQKmfCEOu4uBS:22 a=IjZwj45LgO3ly-622nXo:22 Received: from host31-49-228-163.range31-49.btcentralplus.com ([31.49.228.163]:19935 helo=[192.168.100.100]) by bosauthsmtp08.eigbox.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim) id 1eAaDZ-0004uB-5h; Fri, 03 Nov 2017 07:32:57 -0400 Subject: Re: FreeBSD 11.1 vmx + netmap queues To: Vincenzo Maffione , Santiago Martinez Cc: FreeBSD Net References: <2bd87cdb-9ef7-387a-ba8a-cc7c90702eea@codenetworks.net> From: Santiago Martinez Message-ID: Date: Fri, 3 Nov 2017 11:32:51 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-EN-UserInfo: d94ecc27d8c618b705af6c7847bf2b9d:931c98230c6409dcc37fa7e93b490c27 X-EN-AuthUser: unix@ssbglimited.co.uk Sender: Santiago Martinez X-EN-OrigIP: 31.49.228.163 X-EN-OrigHost: host31-49-228-163.range31-49.btcentralplus.com X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 03 Nov 2017 12:03:19 -0000 Hi Vincenzo, thanks a lot for your help. I tried it this morning and worked like a charm! Cheers Santi On 02/11/17 21:31, Vincenzo Maffione wrote: > Hi, > With vmx driver netmap will use the emulated netmap adapter. On freebsd > netmap still does not have a way to see how many rings an interface has. So > by default will assume 1 tx/rx rings couple for emulated adapter. You can > however change this by sysctl dev.netmap.generic_rings. > > Cheers, > Vincenzo > > Il 2 nov 2017 6:22 PM, "Santiago Martinez" ha scritto: > >> Hi list, hope you guys are doing well. >> >> I have a basic question. Do you know if multiple TX queues are >> supported for vmx + netmap ? >> >> Basically I'm using pkt-gen to generate bulk traffic @10Gbps and its OK >> with packet size >~1000b. >> >> For small packets I should use multiple cores/processes to be able to >> generate the required pps, but pkg-gen complain that I have only one queue. >> >> I tried adding multiple queues for vmx on loader.conf (can verify with >> sysctl) but netmap still complaining there is only one queue. >> >> sysctl -a | grep vmx.1: >> dev.vmx.1.mbuf_load_failed: 0 >> dev.vmx.1.mgetcl_failed: 0 >> dev.vmx.1.defrag_failed: 0 >> dev.vmx.1.defragged: 0 >> dev.vmx.1.nrxqueues: 8 >> dev.vmx.1.ntxqueues: 4 >> dev.vmx.1.max_nrxqueues: 8 >> dev.vmx.1.max_ntxqueues: 4 >> dev.vmx.1.%parent: pci4 >> dev.vmx.1.%pnpinfo: vendor=0x15ad device=0x07b0 subvendor=0x15ad >> subdevice=0x07b0 class=0x020000 >> dev.vmx.1.%location: slot=0 function=0 dbsf=pci0:11:0:0 >> handle=\_SB_.PCI0.PE50.S1F0 >> dev.vmx.1.%driver: vmx >> dev.vmx.1.%desc: VMware VMXNET3 Ethernet Adapter >> >> pkg-gen still saying one queue for vmx: >> >> Sending on netmap:vmx1: 1 queues, 2 threads and 4 cpus. >> >> >> Thanks in advance. >> >> Santiago >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"