From owner-freebsd-net@FreeBSD.ORG Sun Jul 15 02:40:24 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8187516A400; Sun, 15 Jul 2007 02:40:24 +0000 (UTC) (envelope-from karels@redrock.karels.net) Received: from redrock.karels.net (redrock.karels.net [206.196.45.2]) by mx1.freebsd.org (Postfix) with ESMTP id 355A413C471; Sun, 15 Jul 2007 02:40:23 +0000 (UTC) (envelope-from karels@redrock.karels.net) Received: from redrock.karels.net (localhost.karels.net [127.0.0.1]) by redrock.karels.net (8.13.8/8.13.6) with ESMTP id l6F2bAgZ011098; Sat, 14 Jul 2007 21:37:10 -0500 (CDT) (envelope-from karels@redrock.karels.net) Message-Id: <200707150237.l6F2bAgZ011098@redrock.karels.net> To: Robert Watson From: Mike Karels In-reply-to: Your message of Sun, 15 Jul 2007 00:46:27 +0100. <20070715003156.B94899@fledge.watson.org> Date: Sat, 14 Jul 2007 21:37:10 -0500 Sender: karels@karels.net Cc: Stephen.Clark@seclark.us, Sten Daniel Soersdal , Julian Elischer , Bill Moran , freebsd-net@FreeBSD.org Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: karels@karels.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2007 02:40:24 -0000 > A related change that should probably be discussed if we want to think more > about asymmetry in maximum transmission unit is this one: > ---------------------------- > revision 1.98 > date: 2006/06/26 17:54:53; author: andre; state: Exp; lines: +2 -0 > In syncache_respond() do not reply with a MSS that is larger than what > the peer announced to us but make it at least tcp_minmss in size. > Sponsored by: TCP/IP Optimization Fundraise 2005 > ---------------------------- > In this change, we cap the advertised MSS in SYN/ACK to the received > advertised MSS, which presumably avoids an extra PMTU round trip if jumbograms > are enabled on the receiving endpoint. However, it also prevents use of > larger packet sizes if asymmetric MTU is supported. I think I suggested after > this was committed that we at least add an administrative twiddle to > enable/disable this mode of operation, but don't see one in there currently. > Does the Secure Computing scenario use TCP in this way, and is the potential > win in avoiding a PMTU round-trip worth disallowing asymmetric MSS at the TCP > layer? In our case, TCP isn't aware of the MRU, and bases its MSS on the MTU values. However, I don't see any reason for TCP to cap the MSS at the received MSS. If the other end doesn't want to receive more than 1024 bytes, that's no reason to refuse to accept more. Mike From owner-freebsd-net@FreeBSD.ORG Sun Jul 15 03:51:40 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9D54816A403 for ; Sun, 15 Jul 2007 03:51:40 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.freebsd.org (Postfix) with ESMTP id 7563313C428 for ; Sun, 15 Jul 2007 03:51:40 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (rv6oxodc28lp1oc7@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id l6F3pdgL023202; Sat, 14 Jul 2007 20:51:39 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id l6F3pdtf023201; Sat, 14 Jul 2007 20:51:39 -0700 (PDT) (envelope-from jmg) Date: Sat, 14 Jul 2007 20:51:38 -0700 From: John-Mark Gurney To: Sten Daniel Soersdal Message-ID: <20070715035138.GP1221@funkthat.com> Mail-Followup-To: Sten Daniel Soersdal , Stephen.Clark@seclark.us, freebsd-net@freebsd.org References: <46967C5C.5040505@seclark.us> <469772DA.1000700@gmail.com> <46977741.8090301@seclark.us> <4698D290.5080004@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4698D290.5080004@gmail.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: Stephen.Clark@seclark.us, freebsd-net@freebsd.org Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2007 03:51:40 -0000 Sten Daniel Soersdal wrote this message on Sat, Jul 14, 2007 at 15:41 +0200: > You are trying to lower the mtu on the wrong end. > As i said, all hosts on the same L2 needs to share the same mtu. > The router that forwarded you that packet is obviously not using the > same mtu (otherwise it would not be able to forward it to you). > Either you need to lower that routers local interface mtu or you need to > raise your hosts mtu to match that of the router. > Because ALL hosts on the same L2 network need to have the same mtu. I hope that this will not be the cast in the future... I have already fixed -current to follow the host route's MTU instead of the interface's mtu.. This means that you can modify a host's mtu by: route change -mtu And all packets to the host will follow the smaller MTU... This means that we can have the interface mtu set to 9000 (or larger), and change the local network route to have an mtu of 1500 (host routes are cloned from this), and then the mtu daemon can probe the host to see if a larger mtu is possible, and change the route to allow the larger mtu... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Sun Jul 15 09:31:03 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1172116A402 for ; Sun, 15 Jul 2007 09:31:03 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 5EBA313C47E for ; Sun, 15 Jul 2007 09:31:02 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 15 Jul 2007 09:04:21 -0000 Received: from h081217094222.dyn.cm.kabsi.at (EHLO taxman.pepperland) [81.217.94.222] by mail.gmx.net (mp008) with SMTP; 15 Jul 2007 11:04:21 +0200 X-Authenticated: #16703784 X-Provags-ID: V01U2FsdGVkX1/WeUMfuCHW9fBrV2EXAyo4e1ao7RrQbFrjeHsl/L kefk/+jivTRZml From: Stefan Ehmann To: Brian Somers Date: Sun, 15 Jul 2007 11:04:18 +0200 User-Agent: KMail/1.9.7 References: <200704221318.50042.shoesoft@gmx.net> <20070714122132.0142f559@dev.lan.Awfulhak.org> In-Reply-To: <20070714122132.0142f559@dev.lan.Awfulhak.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707151104.18848.shoesoft@gmx.net> X-Y-GMX-Trusted: 0 Cc: freebsd-net@freebsd.org, "Bruce M. Simpson" Subject: Re: tun devices and vpnc in CURRENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2007 09:31:03 -0000 On Saturday 14 July 2007 21:21:32 Brian Somers wrote: > On Sun, 22 Apr 2007 13:18:49 +0200 Stefan Ehmann wrote: > > On CURRENT, each time I stop/start vpnc a new tun device is created. > > Since I restart vpnc every time I re-connect to the network, my ifconfig > > output fills up with tun devices. > > > > On 6.2-RELEASE the tun0 device is reused each time I run vpnc. > > > > Reverting to src/sys/net/if_tun.c rev 1.162 shows the old behaviour. (It > > seems I'm noticing this a bit late) > > > > Is this a bug in either CURRENT or vpnc? > > > > If I set sysctl net.link.tun.devfs_cloning=0, vpnc doesn't work at all: > > # vpnc > > vpnc version 0.4.0 > > kldload: can't load if_tun: File exists > > can't initialise tunnel interface: No such file or directory > > > > This is a CURRENT as of today. Please tell me if you need more info. > > It looks like the problem is in the vpnc-script destroy_tun_device() > function, but even if I add FreeBSD to that, it creates the additional > interfaces. Maybe this is because I'm passing it bogus data and the > connection attempt doesn't cleanup properly either. > > Have you tried talking to the port writer or maintainer? No. I haven't checked if a "ifconfig tunX destroy" works on the commandline. That should reveal the source of the problem. If this works, the problem shouldn't be it if_tun code. Unfortunately, I have no working CURRENT setup ATM, so I can't test it. From owner-freebsd-net@FreeBSD.ORG Sun Jul 15 13:41:12 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3FC6316A401; Sun, 15 Jul 2007 13:41:12 +0000 (UTC) (envelope-from brian@Awfulhak.org) Received: from storm.uk.FreeBSD.org (storm.uk.FreeBSD.org [194.242.157.42]) by mx1.freebsd.org (Postfix) with ESMTP id B77F913C4CE; Sun, 15 Jul 2007 13:41:11 +0000 (UTC) (envelope-from brian@Awfulhak.org) Received: from store.lan.Awfulhak.org (store.lan.Awfulhak.org [172.16.0.35]) by storm.uk.FreeBSD.org (8.14.1/8.14.1) with ESMTP id l6FDf9fI053147; Sun, 15 Jul 2007 14:41:09 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from store.lan.Awfulhak.org (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id DFFF41957CA0; Sun, 15 Jul 2007 13:41:43 +0000 (GMT) Received: from gw.Awfulhak.org (gw.lan.Awfulhak.org [172.16.0.1]) by store.lan.Awfulhak.org (Email Security Appliance) with ESMTP id B55981957C9F; Sun, 15 Jul 2007 13:41:39 +0000 (GMT) Received: from dev.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.14.1/8.14.1) with ESMTP id l6FDf4qp090592; Sun, 15 Jul 2007 06:41:04 -0700 (PDT) (envelope-from brian@Awfulhak.org) Date: Sun, 15 Jul 2007 06:41:03 -0700 From: Brian Somers To: Stefan Ehmann Message-ID: <20070715064103.31694e40@dev.lan.Awfulhak.org> In-Reply-To: <200707151104.18848.shoesoft@gmx.net> References: <200704221318.50042.shoesoft@gmx.net> <20070714122132.0142f559@dev.lan.Awfulhak.org> <200707151104.18848.shoesoft@gmx.net> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.13; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, "Bruce M. Simpson" Subject: Re: tun devices and vpnc in CURRENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2007 13:41:12 -0000 On Sun, 15 Jul 2007 11:04:18 +0200 Stefan Ehmann wrote: > On Saturday 14 July 2007 21:21:32 Brian Somers wrote: > > On Sun, 22 Apr 2007 13:18:49 +0200 Stefan Ehmann wrote: > > > On CURRENT, each time I stop/start vpnc a new tun device is created. > > > Since I restart vpnc every time I re-connect to the network, my ifconfig > > > output fills up with tun devices. > > > > > > On 6.2-RELEASE the tun0 device is reused each time I run vpnc. > > > > > > Reverting to src/sys/net/if_tun.c rev 1.162 shows the old behaviour. (It > > > seems I'm noticing this a bit late) > > > > > > Is this a bug in either CURRENT or vpnc? > > > > > > If I set sysctl net.link.tun.devfs_cloning=0, vpnc doesn't work at all: > > > # vpnc > > > vpnc version 0.4.0 > > > kldload: can't load if_tun: File exists > > > can't initialise tunnel interface: No such file or directory > > > > > > This is a CURRENT as of today. Please tell me if you need more info. > > > > It looks like the problem is in the vpnc-script destroy_tun_device() > > function, but even if I add FreeBSD to that, it creates the additional > > interfaces. Maybe this is because I'm passing it bogus data and the > > connection attempt doesn't cleanup properly either. > > > > Have you tried talking to the port writer or maintainer? > > No. > > I haven't checked if a "ifconfig tunX destroy" works on the commandline. That > should reveal the source of the problem. > > If this works, the problem shouldn't be it if_tun code. Unfortunately, I have > no working CURRENT setup ATM, so I can't test it. Well, I can confirm that 'ifconfig tunN destroy' works ok and has done for some time now. I can also demonstrate that vpnc itself is opening the lowest available tun device by running it with garbage values. Perhaps the author should be told that FreeBSD can destroy interfaces and they'll take it from there? -- Brian Somers Don't _EVER_ lose your sense of humour ! From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 05:10:47 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E609816A403 for ; Mon, 16 Jul 2007 05:10:46 +0000 (UTC) (envelope-from jhealy@swin.edu.au) Received: from mailmonitor.cc.swin.edu.au (mailmonitor.cc.swin.edu.au [136.186.1.65]) by mx1.freebsd.org (Postfix) with ESMTP id 6443513C481 for ; Mon, 16 Jul 2007 05:10:45 +0000 (UTC) (envelope-from jhealy@swin.edu.au) Received: from groupwise.swin.edu.au (Not Verified[136.186.3.218]) by mailmonitor.cc.swin.edu.au with MailMarshal (v6, 1, 4, 441) id ; Mon, 16 Jul 2007 14:50:38 +1000 Received: from [136.186.229.102] (jhealy.caia.swin.edu.au [136.186.229.102]) by groupwise.swin.edu.au with ESMTP; Mon, 16 Jul 2007 14:50:31 +1000 Message-ID: <469AF916.6090901@swin.edu.au> Date: Mon, 16 Jul 2007 14:50:30 +1000 From: James Healy User-Agent: Thunderbird 2.0.0.0 (X11/20070423) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.95.0 Content-Type: multipart/mixed; boundary="------------090909000904020200000908" Cc: Lawrence Stewart , Andrew Subject: Draft email to freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 05:10:47 -0000 This is a multi-part message in MIME format. --------------090909000904020200000908 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We've recently been doing some TCP congestion control research, and have written a small logging module for 6.2 that outputs the cwnd of a tcp flow to a log file. The logging module is called SIFTR and is available on our website: http://caia.swin.edu.au/urp/newtcp/tools.html. In analysing the output, we noticed that despite the rfc3390 sysctl variable being enabled, there were times when flows started with a cwnd equal to 1 MSS instead of 4380 as suggested by rfc3390. We realised the cwnd was constrained to 1 MSS when it's starting value was influenced by the hostcache, so we created the attached patch to view relevant variable values in the tcp_mss function in tcp_input.c. The following are the logged values for 2 sequential ssh sessions to the same host. The first time cwnd is set according to rfc3390, and the second time based on the hostcache. - ------- one: Jul 16 13:31:20 jhealy kernel: setting snd_cwnd according to rfc3390 Jul 16 13:31:20 jhealy kernel: tp->snd_cwnd now set to: 4380 two: Jul 16 13:31:31 jhealy kernel: setting snd_cwnd from hostcache Jul 16 13:31:31 jhealy kernel: tp->snd_cwnd: 1073725440 Jul 16 13:31:31 jhealy kernel: mss: 1448 Jul 16 13:31:31 jhealy kernel: metrics.rmx_cwnd: 14480 Jul 16 13:31:31 jhealy kernel: tp->snd_wnd: 0 Jul 16 13:31:31 jhealy kernel: so->so_snd.sb_hiwat: 33304 Jul 16 13:31:31 jhealy kernel: tp->snd_cwnd now set to: 1448 - ------ The formula used to calculate the cwnd when a relevant entry exists in the hostcache is on line 3054 of tcp_input.c: tp->snd_cwnd = max(mss, min(metrics.rmx_cwnd / 2, min(tp->snd_wnd, so->so_snd.sb_hiwat))); Using the values that we logged earlier, this breaks down as: = max(1448, min(7240, min(0, 33304))) = max(1448, min(7240, 0)) = max(1448, 0) = 1448 Given that the snd_wnd value during the connection initiation seems to always be 0, the cwnd is always going to be set to 1 MSS. This behaviour seems a little odd to us - can anyone shed some light on it? Our assumption is that the use of the hostcache is designed to increase performance where appropriate by seeding the initial cwnd based on past experience. For this section of code to return a cwnd that is successfully influenced by the hostcache, it would seem that the use of tp->snd_wnd should be avoided when the connection is still being initialised: tp->snd_cwnd = max(mss, min(metrics.rmx_cwnd / 2, so->so_snd.sb_hiwat)); James Healy & Lawrence Stewart Centre for Advanced Internet Architectures -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGmvkW4oawkrbYo/kRAkD1AKCMKJfbt3UYb2NCCh+wt4m+SlLuZgCfYJnD stwB3B5BzaMPuyJa5uw3wuQ= =LWnf -----END PGP SIGNATURE----- Swinburne University of Technology CRICOS Provider Code: 00111D NOTICE This e-mail and any attachments are confidential and intended only for the use of the addressee. They may contain information that is privileged or protected by copyright. If you are not the intended recipient, any dissemination, distribution, printing, copying or use is strictly prohibited. The University does not warrant that this e-mail and any attachments are secure and there is also a risk that it may be corrupted in transmission. It is your responsibility to check any attachments for viruses or defects before opening them. If you have received this transmission in error, please contact us on +61 3 9214 8000 and delete it immediately from your system. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. Please consider the environment before printing this email. --------------090909000904020200000908 Content-Type: text/x-patch; name="mss_logger.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mss_logger.patch" --- tcp_input.c.orig Thu Jul 12 10:28:47 2007 +++ tcp_input.c Mon Jul 16 12:29:28 2007 @@ -3051,22 +3067,41 @@ #define TCP_METRICS_CWND #ifdef TCP_METRICS_CWND if (metrics.rmx_cwnd) + { + printf("setting snd_cwnd from hostcache\n"); + printf("tp->snd_cwnd: %li\n", tp->snd_cwnd); + printf("mss: %u\n", mss); + printf("metrics.rmx_cwnd: %li\n", metrics.rmx_cwnd); + printf("tp->snd_wnd: %li\n", tp->snd_wnd); + printf("so->so_snd.sb_hiwat: %u\n", so->so_snd.sb_hiwat); tp->snd_cwnd = max(mss, min(metrics.rmx_cwnd / 2, min(tp->snd_wnd, so->so_snd.sb_hiwat))); + } else #endif if (tcp_do_rfc3390) + { + printf("setting snd_cwnd according to rfc3390\n"); tp->snd_cwnd = min(4 * mss, max(2 * mss, 4380)); + } #ifdef INET6 else if ((isipv6 && in6_localaddr(&inp->in6p_faddr)) || (!isipv6 && in_localaddr(inp->inp_faddr))) + { #else else if (in_localaddr(inp->inp_faddr)) + { #endif + printf("setting snd_cwnd according to local sysctl variable\n"); tp->snd_cwnd = mss * ss_fltsz_local; + } else + { + printf("setting snd_cwnd according to local sysctl variable\n"); tp->snd_cwnd = mss * ss_fltsz; + } + printf("tp->snd_cwnd now set to: %li\n", tp->snd_cwnd); } /* --------------090909000904020200000908-- From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 05:13:48 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A404616A401 for ; Mon, 16 Jul 2007 05:13:48 +0000 (UTC) (envelope-from jhealy@swin.edu.au) Received: from mailmonitor.cc.swin.edu.au (mailmonitor.cc.swin.edu.au [136.186.1.65]) by mx1.freebsd.org (Postfix) with ESMTP id 234F713C4B2 for ; Mon, 16 Jul 2007 05:13:47 +0000 (UTC) (envelope-from jhealy@swin.edu.au) Received: from groupwise.swin.edu.au (Not Verified[136.186.3.218]) by mailmonitor.cc.swin.edu.au with MailMarshal (v6, 1, 4, 441) id ; Mon, 16 Jul 2007 15:13:47 +1000 Received: from [136.186.229.102] (jhealy.caia.swin.edu.au [136.186.229.102]) by groupwise.swin.edu.au with ESMTP; Mon, 16 Jul 2007 15:13:37 +1000 Message-ID: <469AFE80.2090304@swin.edu.au> Date: Mon, 16 Jul 2007 15:13:36 +1000 From: James Healy User-Agent: Thunderbird 2.0.0.0 (X11/20070423) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <469AF916.6090901@swin.edu.au> In-Reply-To: <469AF916.6090901@swin.edu.au> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Lawrence Stewart , Andrew Subject: Odd congestion window behaviour [ was: Draft email to freebsd-net ] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 05:13:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Whoops, we forgot to update the subject of our email. Our previous email isn't a draft. James James Healy wrote: > We've recently been doing some TCP congestion control research, and have > written a small logging module for 6.2 that outputs the cwnd of a tcp > flow to a log file. The logging module is called SIFTR and is available > on our website: http://caia.swin.edu.au/urp/newtcp/tools.html. > > In analysing the output, we noticed that despite the rfc3390 sysctl > variable being enabled, there were times when flows started with a cwnd > equal to 1 MSS instead of 4380 as suggested by rfc3390. > > We realised the cwnd was constrained to 1 MSS when it's starting value > was influenced by the hostcache, so we created the attached patch to > view relevant variable values in the tcp_mss function in tcp_input.c. > > The following are the logged values for 2 sequential ssh sessions to the > same host. The first time cwnd is set according to rfc3390, and the > second time based on the hostcache. > ------- > one: > Jul 16 13:31:20 jhealy kernel: setting snd_cwnd according to rfc3390 > Jul 16 13:31:20 jhealy kernel: tp->snd_cwnd now set to: 4380 > > two: > Jul 16 13:31:31 jhealy kernel: setting snd_cwnd from hostcache > Jul 16 13:31:31 jhealy kernel: tp->snd_cwnd: 1073725440 > Jul 16 13:31:31 jhealy kernel: mss: 1448 > Jul 16 13:31:31 jhealy kernel: metrics.rmx_cwnd: 14480 > Jul 16 13:31:31 jhealy kernel: tp->snd_wnd: 0 > Jul 16 13:31:31 jhealy kernel: so->so_snd.sb_hiwat: 33304 > Jul 16 13:31:31 jhealy kernel: tp->snd_cwnd now set to: 1448 > ------ > The formula used to calculate the cwnd when a relevant entry exists in > the hostcache is on line 3054 of tcp_input.c: > > tp->snd_cwnd = max(mss, min(metrics.rmx_cwnd / 2, min(tp->snd_wnd, > so->so_snd.sb_hiwat))); > > Using the values that we logged earlier, this breaks down as: > > = max(1448, min(7240, min(0, 33304))) > = max(1448, min(7240, 0)) > = max(1448, 0) > = 1448 > > Given that the snd_wnd value during the connection initiation seems to > always be 0, the cwnd is always going to be set to 1 MSS. > > This behaviour seems a little odd to us - can anyone shed some light on > it? Our assumption is that the use of the hostcache is designed to > increase performance where appropriate by seeding the initial cwnd based > on past experience. > > For this section of code to return a cwnd that is successfully > influenced by the hostcache, it would seem that the use of tp->snd_wnd > should be avoided when the connection is still being initialised: > > tp->snd_cwnd = max(mss, min(metrics.rmx_cwnd / 2, so->so_snd.sb_hiwat)); > > James Healy & Lawrence Stewart > Centre for Advanced Internet Architectures -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGmv6A4oawkrbYo/kRAh1SAJ44GZlff6Cj+V9UUgWEmWUBBuqDTwCfRZxC 8uqbdvLyn3XbFScy3qzmbcY= =ngGl -----END PGP SIGNATURE----- Swinburne University of Technology CRICOS Provider Code: 00111D NOTICE This e-mail and any attachments are confidential and intended only for the use of the addressee. They may contain information that is privileged or protected by copyright. If you are not the intended recipient, any dissemination, distribution, printing, copying or use is strictly prohibited. The University does not warrant that this e-mail and any attachments are secure and there is also a risk that it may be corrupted in transmission. It is your responsibility to check any attachments for viruses or defects before opening them. If you have received this transmission in error, please contact us on +61 3 9214 8000 and delete it immediately from your system. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. Please consider the environment before printing this email. From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 11:02:17 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A265916A404 for ; Mon, 16 Jul 2007 11:02:17 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.freebsd.org (Postfix) with ESMTP id 7B67313C4AA for ; Mon, 16 Jul 2007 11:02:17 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 16 Jul 2007 04:02:17 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAI7smkarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,541,1175497200"; d="scan'208"; a="166761018:sNHT26814114" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6GB2GpY004548; Mon, 16 Jul 2007 04:02:16 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6GB2GA0023338; Mon, 16 Jul 2007 11:02:16 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 04:02:16 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 04:02:15 -0700 Message-ID: <469B5069.6080706@cisco.com> Date: Mon, 16 Jul 2007 07:03:05 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Healy References: <469AF916.6090901@swin.edu.au> <469AFE80.2090304@swin.edu.au> In-Reply-To: <469AFE80.2090304@swin.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jul 2007 11:02:15.0901 (UTC) FILETIME=[C51850D0:01C7C798] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1183; t=1184583736; x=1185447736; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20Odd=20congestion=20window=20behaviour=20[=20was=3A=20 Draft=20email=20to=20freebsd-net=0A=20] |Sender:=20; bh=dMvzzWh4XbuU22scbtqdY36V3ZsV0BnwYLcduPltK+4=; b=dt90a36XV4NApPPOWVRWLxi95K+frLMorkUx5LotlNaq72TrX3qirENe7COV+NClSAtuFn2x d+XEXm+BWXMHaeoECnbHMd3ScjSkpx+NPgmVCH2vm9uAEdlawbtjWmLI; Authentication-Results: sj-dkim-3; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); Cc: freebsd-net@freebsd.org, Andrew , Lawrence Stewart Subject: Re: Odd congestion window behaviour [ was: Draft email to freebsd-net ] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 11:02:17 -0000 James Healy wrote: >>This behaviour seems a little odd to us - can anyone shed some light on >>it? Our assumption is that the use of the hostcache is designed to >>increase performance where appropriate by seeding the initial cwnd based >>on past experience. >> >>For this section of code to return a cwnd that is successfully >>influenced by the hostcache, it would seem that the use of tp->snd_wnd >>should be avoided when the connection is still being initialised: >> Oh, one other comment I have on this.. This is the code that used to be buried with comments about Alman et.al. says this is ok to do... if I am remembering right... I.e. where we keep past connection state and use that as a reference for the initial cwnd. I asked Mark about this in the past.. and he said that his paper was mis-interpreted and this is incorrect behavior. If you have no connections up to a peer you should not use any past value for the cwnd... Thats why we don't do it in SCTP. I know a lot of O/S's do this.. but it is not sanctified IMO from the CC experts :-D R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 11:03:03 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 53BE516A404 for ; Mon, 16 Jul 2007 11:03:03 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.freebsd.org (Postfix) with ESMTP id 2C3DF13C4A7 for ; Mon, 16 Jul 2007 11:03:03 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 16 Jul 2007 04:03:03 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAI7smkarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,541,1175497200"; d="scan'208"; a="166761144:sNHT30942189" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6GB32L3005156; Mon, 16 Jul 2007 04:03:02 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6GB2v6E011439; Mon, 16 Jul 2007 11:03:02 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 04:03:02 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 03:59:11 -0700 Message-ID: <469B4FAE.9050208@cisco.com> Date: Mon, 16 Jul 2007 06:59:58 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Healy References: <469AF916.6090901@swin.edu.au> In-Reply-To: <469AF916.6090901@swin.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jul 2007 10:59:12.0126 (UTC) FILETIME=[578E79E0:01C7C798] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6243; t=1184583782; x=1185447782; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20Draft=20email=20to=20freebsd-net |Sender:=20; bh=s4UDteGxZLjMYxso5TAzVi3jLguzZdx/MjKYfJ5pZ+8=; b=aaQ+iY5pJ0S7nGCBz6DQB1m+ELYcJ4o2T4Y30VBvi5cCUAZHcYD0Eqgm8VVj7PXABsQSbV3u FBtD9SqHu9Dkw8xMp8ZVaJxreOLTlvE4EjWdohuPss4ev8o2KmfpTN2v; Authentication-Results: sj-dkim-3; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); Cc: freebsd-net@freebsd.org, Andrew , Lawrence Stewart Subject: Re: Draft email to freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 11:03:03 -0000 James Healy wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > We've recently been doing some TCP congestion control research, and have > written a small logging module for 6.2 that outputs the cwnd of a tcp > flow to a log file. The logging module is called SIFTR and is available > on our website: http://caia.swin.edu.au/urp/newtcp/tools.html. > > In analysing the output, we noticed that despite the rfc3390 sysctl > variable being enabled, there were times when flows started with a cwnd > equal to 1 MSS instead of 4380 as suggested by rfc3390. > > We realised the cwnd was constrained to 1 MSS when it's starting value > was influenced by the hostcache, so we created the attached patch to > view relevant variable values in the tcp_mss function in tcp_input.c. > > The following are the logged values for 2 sequential ssh sessions to the > same host. The first time cwnd is set according to rfc3390, and the > second time based on the hostcache. > - ------- > one: > Jul 16 13:31:20 jhealy kernel: setting snd_cwnd according to rfc3390 > Jul 16 13:31:20 jhealy kernel: tp->snd_cwnd now set to: 4380 > > two: > Jul 16 13:31:31 jhealy kernel: setting snd_cwnd from hostcache > Jul 16 13:31:31 jhealy kernel: tp->snd_cwnd: 1073725440 > Jul 16 13:31:31 jhealy kernel: mss: 1448 > Jul 16 13:31:31 jhealy kernel: metrics.rmx_cwnd: 14480 > Jul 16 13:31:31 jhealy kernel: tp->snd_wnd: 0 > Jul 16 13:31:31 jhealy kernel: so->so_snd.sb_hiwat: 33304 > Jul 16 13:31:31 jhealy kernel: tp->snd_cwnd now set to: 1448 > - ------ > The formula used to calculate the cwnd when a relevant entry exists in > the hostcache is on line 3054 of tcp_input.c: > > tp->snd_cwnd = max(mss, min(metrics.rmx_cwnd / 2, min(tp->snd_wnd, > so->so_snd.sb_hiwat))); > > Using the values that we logged earlier, this breaks down as: > > = max(1448, min(7240, min(0, 33304))) > = max(1448, min(7240, 0)) > = max(1448, 0) > = 1448 > The 0 here fot tp->snd_wnd is the problem IMO.. seems to me one should put a reasonable default on the "estimated" peers send window when a connection starts... say 4360 :-D Then what will happen is you will get the number you exepct... so mabye it should be: tp->snd_cwnd = max(mss, min(metrics.rmx_cwnd / 2, min( min(tp->snd_wnd,4380),so->so_snd.sb_hiwat))); :-D R > Given that the snd_wnd value during the connection initiation seems to > always be 0, the cwnd is always going to be set to 1 MSS. > > This behaviour seems a little odd to us - can anyone shed some light on > it? Our assumption is that the use of the hostcache is designed to > increase performance where appropriate by seeding the initial cwnd based > on past experience. > > For this section of code to return a cwnd that is successfully > influenced by the hostcache, it would seem that the use of tp->snd_wnd > should be avoided when the connection is still being initialised: > > tp->snd_cwnd = max(mss, min(metrics.rmx_cwnd / 2, so->so_snd.sb_hiwat)); > > James Healy & Lawrence Stewart > Centre for Advanced Internet Architectures > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (FreeBSD) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGmvkW4oawkrbYo/kRAkD1AKCMKJfbt3UYb2NCCh+wt4m+SlLuZgCfYJnD > stwB3B5BzaMPuyJa5uw3wuQ= > =LWnf > -----END PGP SIGNATURE----- > > Swinburne University of Technology > CRICOS Provider Code: 00111D > > NOTICE > This e-mail and any attachments are confidential and intended only for the use of the addressee. They may contain information that is privileged or protected by copyright. If you are not the intended recipient, any dissemination, distribution, printing, copying or use is strictly prohibited. The University does not warrant that this e-mail and any attachments are secure and there is also a risk that it may be corrupted in transmission. It is your responsibility to check any attachments for viruses or defects before opening them. If you have received this transmission in error, please contact us on +61 3 9214 8000 and delete it immediately from your system. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. > > Please consider the environment before printing this email. > > > ------------------------------------------------------------------------ > > --- tcp_input.c.orig Thu Jul 12 10:28:47 2007 > +++ tcp_input.c Mon Jul 16 12:29:28 2007 > @@ -3051,22 +3067,41 @@ > #define TCP_METRICS_CWND > #ifdef TCP_METRICS_CWND > if (metrics.rmx_cwnd) > + { > + printf("setting snd_cwnd from hostcache\n"); > + printf("tp->snd_cwnd: %li\n", tp->snd_cwnd); > + printf("mss: %u\n", mss); > + printf("metrics.rmx_cwnd: %li\n", metrics.rmx_cwnd); > + printf("tp->snd_wnd: %li\n", tp->snd_wnd); > + printf("so->so_snd.sb_hiwat: %u\n", so->so_snd.sb_hiwat); > tp->snd_cwnd = max(mss, > min(metrics.rmx_cwnd / 2, > min(tp->snd_wnd, so->so_snd.sb_hiwat))); > + } > else > #endif > if (tcp_do_rfc3390) > + { > + printf("setting snd_cwnd according to rfc3390\n"); > tp->snd_cwnd = min(4 * mss, max(2 * mss, 4380)); > + } > #ifdef INET6 > else if ((isipv6 && in6_localaddr(&inp->in6p_faddr)) || > (!isipv6 && in_localaddr(inp->inp_faddr))) > + { > #else > else if (in_localaddr(inp->inp_faddr)) > + { > #endif > + printf("setting snd_cwnd according to local sysctl variable\n"); > tp->snd_cwnd = mss * ss_fltsz_local; > + } > else > + { > + printf("setting snd_cwnd according to local sysctl variable\n"); > tp->snd_cwnd = mss * ss_fltsz; > + } > + printf("tp->snd_cwnd now set to: %li\n", tp->snd_cwnd); > } > > /* > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 11:08:26 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A7F8D16A401 for ; Mon, 16 Jul 2007 11:08:26 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 7D69813C4B6 for ; Mon, 16 Jul 2007 11:08:26 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l6GB8QW3018076 for ; Mon, 16 Jul 2007 11:08:26 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l6GB8P2F018072 for freebsd-net@FreeBSD.org; Mon, 16 Jul 2007 11:08:25 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 16 Jul 2007 11:08:25 GMT Message-Id: <200707161108.l6GB8P2F018072@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 11:08:26 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/109406 net [ndis] Broadcom WLAN driver 4.100.15.5 doesn't work wi o kern/110959 net [ipsec] Filtering incoming packets with enc0 does not o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net IP v4 udp fragmented packet reject o kern/113359 net [ipv6] panic sbdrop after ICMP6, packet too big o kern/113457 net [ipv6] deadlock occurs if a tunnel goes down while the o kern/113842 net [ipv6] PF_INET6 proto domain state can't be cleared wi 16 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] IP Encapsulation mask_match() returns wrong o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/103253 net inconsistent behaviour in arp reply of a bridge o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/112612 net [lo] Traffic via additional lo(4) interface shows up o o kern/112654 net [pcn] Kernel panic upon if_pcn module load on a Netfin o kern/112886 net [broadcom]: Wifi card not detected o kern/114095 net [carp] carp+pf delay with high state limit 15 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 14:20:07 2007 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6335F16A405 for ; Mon, 16 Jul 2007 14:20:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 4CD1E13C4A8 for ; Mon, 16 Jul 2007 14:20:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l6GEK6f2041689 for ; Mon, 16 Jul 2007 14:20:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l6GEK6is041684; Mon, 16 Jul 2007 14:20:06 GMT (envelope-from gnats) Date: Mon, 16 Jul 2007 14:20:06 GMT Message-Id: <200707161420.l6GEK6is041684@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Cristian KLEIN Cc: Subject: Re: kern/112612: [lo] Traffic via additional lo(4) interface shows up on lo0 in bpf(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Cristian KLEIN List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 14:20:07 -0000 The following reply was made to PR kern/112612; it has been noted by GNATS. From: Cristian KLEIN To: bug-followup@FreeBSD.org, yar@comp.chem.msu.su Cc: Subject: Re: kern/112612: [lo] Traffic via additional lo(4) interface shows up on lo0 in bpf(4) Date: Mon, 16 Jul 2007 17:18:33 +0300 This is a multi-part message in MIME format. --------------070102080802050402090903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The following patch is against -CURRENT: cd /usr/src patch < if_loop.patch Recompile the kernel and it should work. --------------070102080802050402090903 Content-Type: text/x-patch; name="if_loop.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="if_loop.patch" --- sys/net/if_loop.c.orig 2007-02-09 02:09:35.000000000 +0200 +++ sys/net/if_loop.c 2007-07-16 17:02:31.438464106 +0300 @@ -274,15 +274,15 @@ bpf_mtap(ifp->if_bpf, m); } } else { - if (bpf_peers_present(loif->if_bpf)) { - if ((m->m_flags & M_MCAST) == 0 || loif == ifp) { + if (bpf_peers_present(ifp->if_bpf)) { + if ((m->m_flags & M_MCAST) == 0 || (ifp->if_flags == IFF_LOOPBACK)) { /* XXX beware sizeof(af) != 4 */ u_int32_t af1 = af; /* * We need to prepend the address family. */ - bpf_mtap2(loif->if_bpf, &af1, sizeof(af1), m); + bpf_mtap2(ifp->if_bpf, &af1, sizeof(af1), m); } } } --------------070102080802050402090903-- From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 15:56:09 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4460316A400 for ; Mon, 16 Jul 2007 15:56:09 +0000 (UTC) (envelope-from netslists@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.freebsd.org (Postfix) with ESMTP id B9E4713C494 for ; Mon, 16 Jul 2007 15:56:08 +0000 (UTC) (envelope-from netslists@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so1126306uge for ; Mon, 16 Jul 2007 08:56:07 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=qXMVm4EB/9L5i+1L7o0QnrZpfL8+AOYqvfU8FAP9mBpVD8RvWrT7fhdqOc52YK5gZnRScSV985IPLLu2/u0oxc8HrOYCU9KjYyaBwL6m+A6vLM+FFQWwMPRYD1J5ruo+ufkO9I0I3XvE605SMjFAr16JOn+OWyXcmIqyL9jUYMk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=M1d81WEmZmwXeAAmqNpLgu2o5mRrT8NE3u1dMzDB9k6rJiUcOoVA6NMzYRZRwnzvUdrhIfbOeGNNEV6qeLIQHhS4TQQNsKUENF2Hi3VEivpPZycikvfVYks+4Ktri21uSFZs0n3Yr2SiljdizuRYUtFsslfXHNFONCRyQ9TJwzI= Received: by 10.86.60.7 with SMTP id i7mr3666400fga.1184601367193; Mon, 16 Jul 2007 08:56:07 -0700 (PDT) Received: from ?192.168.9.8? ( [91.135.49.10]) by mx.google.com with ESMTP id p9sm10304336fkb.2007.07.16.08.56.06 (version=SSLv3 cipher=RC4-MD5); Mon, 16 Jul 2007 08:56:06 -0700 (PDT) Message-ID: <469B9516.2090904@gmail.com> Date: Mon, 16 Jul 2007 17:56:06 +0200 From: Sten Daniel Soersdal User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Stephen.Clark@seclark.us References: <46967C5C.5040505@seclark.us> <469772DA.1000700@gmail.com> <46977741.8090301@seclark.us> <4698D290.5080004@gmail.com> <46992021.8090603@seclark.us> In-Reply-To: <46992021.8090603@seclark.us> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 15:56:09 -0000 Stephen Clark wrote: > Sten Daniel Soersdal wrote: > >> Stephen Clark wrote: >> >> >>> Sten Daniel Soersdal wrote: >>> >>> >>>> Stephen Clark wrote: >>>> >>>> >>>> >>>>> Hello, >>>>> >>>>> Did something change in 6.2? If my mtu size on rl0 is 1280 it won't >>>>> accept a larger incomming packet. >>>>> >>>>> kernel: rl0: discard oversize frame (ether type 800 flags 3 len >>>>> 1514 >>>>>> max >>>>>> >>>>> 1294) >>>>> >>>>> >>>> That is what to be expected. >>>> Incoming interface must have mtu set to the same mtu as all other >>>> hosts on the same L2 network. If mtu is set to the same as all other >>>> hosts, then it is impossible to receive a frame that is too large >>>> (assuming everything works). >>>> >>>> >>>> >>>> >>>>> I don't think it worked this way in the past. >>>>> >>>>> Won't this affect pmtud? >>>>> >>>>> >>>> Incoming interface must have its mtu set to large enough to receive >>>> the frame. Outgoing interface, on the other hand, can be lower. >>>> >>>> For pmtud to work you need to be able to receive packets on an >>>> interface with sufficiently set mtu, but the exitting interface can >>>> have a lower mtu configured. Thus the router can accept the incoming >>>> packet but may drop and notify on a frame that is too large to exit >>>> the outgoing interface (assuming DF is set). >>>> >>>> >>>> >>>> >>>>> man page for ifconfig says mtu limits size of "transmission" not >>>>> reception. >>>>> >>>>> "mtu n Set the maximum transmission unit of the interface to n, >>>>> default >>>>> is interface specific." >>>>> >>>>> >>>> Perhaps the man author considered reception to be implied? >>>> >>>> In any case, enforcing this on incoming packets is correct behavior. >>>> >>>> >>>> >>>> >>> But shouldn't an icmp be generated back to the system sending the >>> packet that is >>> being dropped? This is not happening. So the connection stalls. >>> >>> client mtu 1500 <-> |rl0 mtu 1500 FreeBSD Router rl1 mtu 1280| <-> >>> some host on internet >>> client sends syn saying i can do mss=1460 >>> host sends syn saying i can do mss=1460 >>> host tries to send packet of 1460 it get silently dropped. connection >>> stalls. >>> >>> >> >> You are trying to lower the mtu on the wrong end. >> As i said, all hosts on the same L2 needs to share the same mtu. >> The router that forwarded you that packet is obviously not using the >> same mtu (otherwise it would not be able to forward it to you). >> Either you need to lower that routers local interface mtu or you need >> to raise your hosts mtu to match that of the router. >> Because ALL hosts on the same L2 network need to have the same mtu. >> >> >> > I don't disagree - my issue is that this is new behavior in FreeBSD 6.x > that did not exist in > FreeBSD 4.x. > > However as many have said in thread : > > >> From RFC-1122, and memorialized on the working group coffee cup on my > bookshelf: > > Be liberal in what you accept, and > conservative in what you send > > (attributed to RFC-791, but paraphrased; also in RFC-793; for those > who don't recognize them, these are the original IP and TCP specs.) > > >>> The ability to receive packets larger than mtu was not accidental. >>> This should be fixed, if it is, as is suggested, a deliberate change. >> >> > > I'd be happy to see the change undone as well. I (well, our test > group) found this change in a similar way, and it didn't agree with > our previous usage. You make compelling argument about this. I was under the assumption that you were YANN (Yet Another Network Newbie). Please excuse my assumption and the reiteration of my first arguments. I guess it wouldn't hurt for the operating system to accept larger frames, as long as only the correctly sized frames are transmitted. There are alot of people, including myself, that assume a host can't receive a frame that is larger than MTU. Perhaps it should be noted in the man pages about this behavior in addition? -- Sten Daniel Soersdal From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 16:56:16 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81AA316A400 for ; Mon, 16 Jul 2007 16:56:16 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: from smtpauth03.prod.mesa1.secureserver.net (smtpauth03.prod.mesa1.secureserver.net [64.202.165.183]) by mx1.freebsd.org (Postfix) with SMTP id 2FBA313C4A3 for ; Mon, 16 Jul 2007 16:56:16 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: (qmail 19091 invoked from network); 16 Jul 2007 16:56:13 -0000 Received: from unknown (24.144.77.243) by smtpauth03.prod.mesa1.secureserver.net (64.202.165.183) with ESMTP; 16 Jul 2007 16:56:13 -0000 Message-ID: <469BA32D.8040706@seclark.us> Date: Mon, 16 Jul 2007 12:56:13 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; m18) Gecko/20010110 Netscape6/6.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wes Peters References: <46967C5C.5040505@seclark.us> <469772DA.1000700@gmail.com> <46977741.8090301@seclark.us> <4698D290.5080004@gmail.com> <46992021.8090603@seclark.us> <469B9516.2090904@gmail.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Sten Daniel Soersdal Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Clark@seclark.us List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 16:56:16 -0000 Wes Peters wrote: >On 7/16/07, Sten Daniel Soersdal wrote: > > >>I guess it wouldn't hurt for the operating system to accept larger >>frames, as long as only the correctly sized frames are transmitted. >> >>There are alot of people, including myself, that assume a host can't >>receive a frame that is larger than MTU. Perhaps it should be noted in >>the man pages about this behavior in addition? >> >> > >I've bumped into this issue several times before. A look at the >ifconfig man page will show a way to set the interface mtu, but not >the mru. FreeBSD has always used the mtu as the mru for the > > This is not the case in FreeBSD 4.9 - It would gladly accept packets on an interface that were larger than the MTU for that interface. >interface, which is arguably wrong. In every case I've encountered >this problem, the user had truly mis-configured some part of the >network and correct configuration solved the problem, so I've never >been fully convinced it needed to be fixed. > > > > -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 17:15:45 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C640716A404 for ; Mon, 16 Jul 2007 17:15:45 +0000 (UTC) (envelope-from barnaclewes@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id 5921C13C461 for ; Mon, 16 Jul 2007 17:15:45 +0000 (UTC) (envelope-from barnaclewes@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so1146126uge for ; Mon, 16 Jul 2007 10:15:44 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YslY5femMU6QYqpyT0P6HnDs6mYwLa2PeFkFhfv/5Ix6lYDJsYtFxq+xhg416TPmRTwrMrRYhBIE8HHfOweqrg1ZbUJOBpQnLhw0IZzn15onhnj3eBqHnRYT+plw0zemj+qZv66whtydW8Cx71Kb8sNKtjoaCf9Vv4OkoLZMLho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=K2V4spcDv+cmAo3O+m8GICv8wf6o2rp/I8lNouZ7Qrexmxs/HnMbS0E+208Y88+vNUmlrAY2/QqqDvHEnDwDAmKrwNmKmpvodEcAU43c0gtlfOgQXfUM8gvJLSyH70nKztmavMIVjsFVUQHmpUzeACcsRtoA+vQtyN8IyPBshCo= Received: by 10.78.180.16 with SMTP id c16mr1232351huf.1184604519930; Mon, 16 Jul 2007 09:48:39 -0700 (PDT) Received: by 10.78.201.4 with HTTP; Mon, 16 Jul 2007 09:48:39 -0700 (PDT) Message-ID: Date: Mon, 16 Jul 2007 09:48:39 -0700 From: "Wes Peters" To: "Sten Daniel Soersdal" In-Reply-To: <469B9516.2090904@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46967C5C.5040505@seclark.us> <469772DA.1000700@gmail.com> <46977741.8090301@seclark.us> <4698D290.5080004@gmail.com> <46992021.8090603@seclark.us> <469B9516.2090904@gmail.com> Cc: Stephen.Clark@seclark.us, freebsd-net@freebsd.org Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 17:15:45 -0000 On 7/16/07, Sten Daniel Soersdal wrote: > > I guess it wouldn't hurt for the operating system to accept larger > frames, as long as only the correctly sized frames are transmitted. > > There are alot of people, including myself, that assume a host can't > receive a frame that is larger than MTU. Perhaps it should be noted in > the man pages about this behavior in addition? I've bumped into this issue several times before. A look at the ifconfig man page will show a way to set the interface mtu, but not the mru. FreeBSD has always used the mtu as the mru for the interface, which is arguably wrong. In every case I've encountered this problem, the user had truly mis-configured some part of the network and correct configuration solved the problem, so I've never been fully convinced it needed to be fixed. -- Against stupidity the very gods Themselves contend in vain. Friedrich Schiller From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 18:03:11 2007 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D23916A409 for ; Mon, 16 Jul 2007 18:03:11 +0000 (UTC) (envelope-from isnya@ipnt.net) Received: from agsb-4db0e330.pool.einsundeins.de (agsb-4db0e330.pool.einsundeins.de [77.176.227.48]) by mx1.freebsd.org (Postfix) with SMTP id AE41E13C4DD for ; Mon, 16 Jul 2007 18:03:10 +0000 (UTC) (envelope-from isnya@ipnt.net) Received: (qmail 2595 invoked from network); Mon, 16 Jul 2007 20:03:14 +0200 Received: from unknown (HELO lysp) (45.96.76.44) by agsb-4db0e330.pool.einsundeins.de with SMTP; Mon, 16 Jul 2007 20:03:14 +0200 Message-ID: <469BB2E2.2020304@akamail.com> Date: Mon, 16 Jul 2007 20:03:14 +0200 From: Irene Brandt User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: freebsd-net@hub.freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: suspenders X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 18:03:11 -0000 SZSN Announces Sales Income UP 37.6% Over Last Year! Shandong Zhouyuan Seed and Nursery Co., Ltd (SZSN) $0.38 UP 15% (9:36AM EST) SZSN continues to climb as more great news unfolds. Read the news and get on SZSN today! For many, the dead of winter is upon us. Is experience enough? RSS feeds can provide thermographers with up-to-the minute news and information on thermography and related PdM and NDT topics. It is usually two or three percent of the property value. Typical extensions for image files include JPEG, BMP, GIF, and TIFF. Use accurate language when speaking or writing about your inspections. Images were taken at sunset following a sunny day. This list of notifications is called an "RSS Feed. The scope of the inspection consists of: Moisture Survey, Energy Survey, Leak Detection, Fungi and Wood Destroying Organisms. Here are some ways to reduce the risks. IR home inspections provide baseline moisture and temperature documentation. There was a lawsuit and the homeowner received a large cash settlement. Should the requestor persist, the thermographer should decline to perform the inspection altogether. Check the soundness of the wood as you go by, hitting the truss in various areas with a hammer or screwdriver. From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 18:20:08 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 051FE16A403 for ; Mon, 16 Jul 2007 18:20:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id B6AE213C491 for ; Mon, 16 Jul 2007 18:20:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id E34E741C5CE; Mon, 16 Jul 2007 20:20:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 3uzTNFS99+5E; Mon, 16 Jul 2007 20:20:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 71AFF41C533; Mon, 16 Jul 2007 20:20:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 70199444885; Mon, 16 Jul 2007 18:19:29 +0000 (UTC) Date: Mon, 16 Jul 2007 18:19:29 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: David Cornejo In-Reply-To: <4ab61a80706200336l49f16764t1d95c61f0dd323e5@mail.gmail.com> Message-ID: <20070716181837.Y31116@maildrop.int.zabbadoz.net> References: <4678896b.1cef600a.1a79.7312@mx.google.com> <20070620100441.E98813@maildrop.int.zabbadoz.net> <4ab61a80706200336l49f16764t1d95c61f0dd323e5@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: soekris/sis tx checksum problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 18:20:08 -0000 On Wed, 20 Jun 2007, David Cornejo wrote: Hi, > the remote machine sees bad checksums - netstat indicates that > received packets are being discarded because of bad checksums. > > -txcsum has no effect, I don't think (at least mine) sis support > offloading checksums - the only if flags seem to be VLAN_MTU yeah off course. Did you find any solution? I can reproduce this with a fairly up-to-date HEAD now. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 19:33:43 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9503516A402 for ; Mon, 16 Jul 2007 19:33:43 +0000 (UTC) (envelope-from dave@dogwood.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.188]) by mx1.freebsd.org (Postfix) with ESMTP id 2C78013C48D for ; Mon, 16 Jul 2007 19:33:40 +0000 (UTC) (envelope-from dave@dogwood.com) Received: by mu-out-0910.google.com with SMTP id w9so1537470mue for ; Mon, 16 Jul 2007 12:33:39 -0700 (PDT) Received: by 10.82.127.14 with SMTP id z14mr5103488buc.1184614419239; Mon, 16 Jul 2007 12:33:39 -0700 (PDT) Received: by 10.82.185.10 with HTTP; Mon, 16 Jul 2007 12:33:39 -0700 (PDT) Message-ID: <4ab61a80707161233m11e49f2brac162a882f4ebbd7@mail.gmail.com> Date: Mon, 16 Jul 2007 09:33:39 -1000 From: "David Cornejo" To: "Bjoern A. Zeeb" In-Reply-To: <20070716181837.Y31116@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4678896b.1cef600a.1a79.7312@mx.google.com> <20070620100441.E98813@maildrop.int.zabbadoz.net> <4ab61a80706200336l49f16764t1d95c61f0dd323e5@mail.gmail.com> <20070716181837.Y31116@maildrop.int.zabbadoz.net> Cc: freebsd-net@freebsd.org Subject: Re: soekris/sis tx checksum problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 19:33:43 -0000 I eventually reinstalled the OS from a recent snapshot then updated it to the latest CURRENT and it works fine now :-( dave c On 7/16/07, Bjoern A. Zeeb wrote: > On Wed, 20 Jun 2007, David Cornejo wrote: > > Hi, > > > the remote machine sees bad checksums - netstat indicates that > > received packets are being discarded because of bad checksums. > > > > -txcsum has no effect, I don't think (at least mine) sis support > > offloading checksums - the only if flags seem to be VLAN_MTU > > yeah off course. > > Did you find any solution? I can reproduce this with a fairly up-to-date > HEAD now. > > -- > Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT > Software is harder than hardware so better get it right the first time. > From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 20:15:07 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8942916A401 for ; Mon, 16 Jul 2007 20:15:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 460A213C441 for ; Mon, 16 Jul 2007 20:15:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 9A2A941C5D3; Mon, 16 Jul 2007 22:15:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id cEFgC-dOxtDr; Mon, 16 Jul 2007 22:15:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 48BB441C5EA; Mon, 16 Jul 2007 22:15:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 638D3444885; Mon, 16 Jul 2007 20:14:14 +0000 (UTC) Date: Mon, 16 Jul 2007 20:14:14 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: David Cornejo In-Reply-To: <4ab61a80707161233m11e49f2brac162a882f4ebbd7@mail.gmail.com> Message-ID: <20070716201218.U31116@maildrop.int.zabbadoz.net> References: <4678896b.1cef600a.1a79.7312@mx.google.com> <20070620100441.E98813@maildrop.int.zabbadoz.net> <4ab61a80706200336l49f16764t1d95c61f0dd323e5@mail.gmail.com> <20070716181837.Y31116@maildrop.int.zabbadoz.net> <4ab61a80707161233m11e49f2brac162a882f4ebbd7@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: soekris/sis tx checksum problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 20:15:07 -0000 On Mon, 16 Jul 2007, David Cornejo wrote: > I eventually reinstalled the OS from a recent snapshot then updated it > to the latest CURRENT and it works fine now :-( Hmm I am using CURRENT from today and I culd see the issue. I set sysctl net.inet.udp.checksum=0 to get things working temporary. In addition I am backing out a change from May and shall see if that helps. Did you have/do you have any private patches in your tree? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 20:24:00 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 54A6F16A400 for ; Mon, 16 Jul 2007 20:24:00 +0000 (UTC) (envelope-from dave@dogwood.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.freebsd.org (Postfix) with ESMTP id E57F713C4A3 for ; Mon, 16 Jul 2007 20:23:59 +0000 (UTC) (envelope-from dave@dogwood.com) Received: by nf-out-0910.google.com with SMTP id b2so95743nfb for ; Mon, 16 Jul 2007 13:23:58 -0700 (PDT) Received: by 10.82.106.14 with SMTP id e14mr5134386buc.1184617437947; Mon, 16 Jul 2007 13:23:57 -0700 (PDT) Received: by 10.82.185.10 with HTTP; Mon, 16 Jul 2007 13:23:57 -0700 (PDT) Message-ID: <4ab61a80707161323l57b36049u6be952529f76c4e6@mail.gmail.com> Date: Mon, 16 Jul 2007 10:23:57 -1000 From: "David Cornejo" To: "Bjoern A. Zeeb" In-Reply-To: <20070716201218.U31116@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4678896b.1cef600a.1a79.7312@mx.google.com> <20070620100441.E98813@maildrop.int.zabbadoz.net> <4ab61a80706200336l49f16764t1d95c61f0dd323e5@mail.gmail.com> <20070716181837.Y31116@maildrop.int.zabbadoz.net> <4ab61a80707161233m11e49f2brac162a882f4ebbd7@mail.gmail.com> <20070716201218.U31116@maildrop.int.zabbadoz.net> Cc: freebsd-net@freebsd.org Subject: Re: soekris/sis tx checksum problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 20:24:00 -0000 it was the stock tree On 7/16/07, Bjoern A. Zeeb wrote: > On Mon, 16 Jul 2007, David Cornejo wrote: > > > I eventually reinstalled the OS from a recent snapshot then updated it > > to the latest CURRENT and it works fine now :-( > > Hmm I am using CURRENT from today and I culd see the issue. > > I set sysctl net.inet.udp.checksum=0 to get things working temporary. > > In addition I am backing out a change from May and shall see if that > helps. > > Did you have/do you have any private patches in your tree? > > -- > Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT > Software is harder than hardware so better get it right the first time. > From owner-freebsd-net@FreeBSD.ORG Tue Jul 17 02:22:08 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 39EB416A402 for ; Tue, 17 Jul 2007 02:22:08 +0000 (UTC) (envelope-from jhealy@swin.edu.au) Received: from mailmonitor.cc.swin.edu.au (mailmonitor.cc.swin.edu.au [136.186.1.65]) by mx1.freebsd.org (Postfix) with ESMTP id 9E3BB13C474 for ; Tue, 17 Jul 2007 02:22:07 +0000 (UTC) (envelope-from jhealy@swin.edu.au) Received: from groupwise.swin.edu.au (Not Verified[136.186.3.218]) by mailmonitor.cc.swin.edu.au with MailMarshal (v6, 1, 4, 441) id ; Tue, 17 Jul 2007 12:22:06 +1000 Received: from [136.186.229.102] (jhealy.caia.swin.edu.au [136.186.229.102]) by groupwise.swin.edu.au with ESMTP; Tue, 17 Jul 2007 12:22:03 +1000 Message-ID: <469C27CB.9090906@swin.edu.au> Date: Tue, 17 Jul 2007 12:22:03 +1000 From: James Healy User-Agent: Thunderbird 2.0.0.0 (X11/20070423) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <469AF916.6090901@swin.edu.au> <469AFE80.2090304@swin.edu.au> <469B5069.6080706@cisco.com> In-Reply-To: <469B5069.6080706@cisco.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Andrew Subject: Re: Odd congestion window behaviour [ was: Draft email to freebsd-net ] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 02:22:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I.e. where we keep past connection state and use that > as a reference for the initial cwnd. I asked Mark about > this in the past.. and he said that his paper was > mis-interpreted and this is incorrect behavior. If you > have no connections up to a peer you should not use any > past value for the cwnd... So it's possible that the inital cwnd shouldn't be set by the hostcache at all? If this was the case, does that mean we'd just use the rfc 3390 logic if enabled, with fallback to the manual sysctl variables as a last resort? James -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGnCfL4oawkrbYo/kRAuRMAJ47fESbkRB076y7w4hUA25FJp8i+wCcCg13 aMQJpkHxjy6RdWXVoGmHhX4= =QYKp -----END PGP SIGNATURE----- Swinburne University of Technology CRICOS Provider Code: 00111D NOTICE This e-mail and any attachments are confidential and intended only for the use of the addressee. They may contain information that is privileged or protected by copyright. If you are not the intended recipient, any dissemination, distribution, printing, copying or use is strictly prohibited. The University does not warrant that this e-mail and any attachments are secure and there is also a risk that it may be corrupted in transmission. It is your responsibility to check any attachments for viruses or defects before opening them. If you have received this transmission in error, please contact us on +61 3 9214 8000 and delete it immediately from your system. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. Please consider the environment before printing this email. From owner-freebsd-net@FreeBSD.ORG Tue Jul 17 10:58:27 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8475B16A400 for ; Tue, 17 Jul 2007 10:58:27 +0000 (UTC) (envelope-from paketix@bluewin.ch) Received: from mx25.bluewin.ch (mx25.bluewin.ch [195.186.18.39]) by mx1.freebsd.org (Postfix) with ESMTP id 19BDF13C471 for ; Tue, 17 Jul 2007 10:58:26 +0000 (UTC) (envelope-from paketix@bluewin.ch) Received: from hbnnbsddev03.sharedtcs.net (213.3.8.216) by mx25.bluewin.ch (Bluewin 7.3.122) id 4689B50D01AA005D for freebsd-net@freebsd.org; Tue, 17 Jul 2007 10:58:25 +0000 Received: from hbnnbsddev03.sharedtcs.net (localhost.sharedtcs.net [127.0.0.1]) by hbnnbsddev03.sharedtcs.net (8.13.8/8.13.8) with ESMTP id l6HB1ulr037955 for ; Tue, 17 Jul 2007 13:01:56 +0200 (CEST) (envelope-from tbeoepa1@hbnnbsddev03.sharedtcs.net) Received: (from tbeoepa1@localhost) by hbnnbsddev03.sharedtcs.net (8.13.8/8.13.8/Submit) id l6HB1uBk037954 for freebsd-net@freebsd.org; Tue, 17 Jul 2007 13:01:56 +0200 (CEST) (envelope-from tbeoepa1) Date: Tue, 17 Jul 2007 13:01:56 +0200 From: Patrick Oeschger To: freebsd-net@freebsd.org Message-ID: <20070717110156.GA37722@hbnnbsddev03.sharedtcs.net> Mail-Followup-To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: em(4)/82571eb: fifo not dma'ed to host memory X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 10:58:27 -0000 bug description for 7.0-CURRENT - em(4) driver version 6.5.3 - frame reception is not possible (missed packets counter incrementing) - frame transmission is not possible (driver watchdog fires) bug exists also on 6.2-RELENG - em(4) driver version 6.2.9 bug does *not* exist on 6.1-RELENG - em(4) driver version 3.2.18 jack vogel told me that the i82571 can be tricky when having a bunch of them - i have 8 such interfaces on the motherboard so i disabled 7 of them with a modified em_probe (if_em.c) running the driver on just one interface does not change the behaviour - init of the interface during verbose boot looks fine - bringing the interface to upness looks fine too - RDH0/RDT0 registers do *not* increment after frame reception - frames suspected *not* getting dma'ed from fifo to host memory - RX interrupt suspected *not* being sent to the driver see dmesg and debug ouput for futher details... anybody having some experience with this issue? any advice to track this further down? thanks, pat diff for em_probe subr to ensure that only one interface is init'ed: freebsd70# diff -u if_em.c.orig if_em.c --- if_em.c.orig Tue Jul 17 11:18:18 2007 +++ if_em.c Tue Jul 17 06:34:48 2007 @@ -379,6 +379,10 @@ INIT_DEBUGOUT("em_probe: begin"); + // prevent init of all em(4) devices except pci9/0/0 + if(pci_get_bus(dev) != 0x09 || pci_get_slot(dev) != 0x00 || + pci_get_function(dev) != 0x00) + return (ENXIO); + pci_vendor_id = pci_get_vendor(dev); if (pci_vendor_id != EM_VENDOR_ID) return (ENXIO); excerpt of verbose dmesg looks fine for em0: pcib9: irq 19 at device 11.0 on pci2 pcib9: secondary bus 9 pcib9: subordinate bus 9 pcib9: I/O decode 0x6000-0x6fff pcib9: memory decode 0xfd700000-0xfd7fffff pcib9: prefetched decode 0xfce00000-0xfcefffff pci9: on pcib9 pci9: physical bus=9 found-> vendor=0x8086, dev=0x105e, revid=0x06 bus=9, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0, size 17, memory disabled map[14]: type Memory, range 32, base 0, size 17, memory disabled map[18]: type I/O Port, range 32, base 0, size 5, port disabled found-> vendor=0x8086, dev=0x105e, revid=0x06 bus=9, slot=0, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0, size 17, memory disabled map[14]: type Memory, range 32, base 0, size 17, memory disabled map[18]: type I/O Port, range 32, base 0, size 5, port disabled em0: at device 0.0 on pci9 pcib9: em0 requested memory range 0xfd700000-0xfd7fffff: good pcib2: em0 requested memory range 0xfd700000-0xfd7fffff: good pcib1: em0 requested memory range 0xfd700000-0xfd7fffff: good em0: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at 0xfd700000 pcib1: matched entry for 1.0.INTD pcib1: slot 0 INTD hardwired to IRQ 19 pcib2: slot 11 INTA is routed to irq 19 pcib9: slot 0 INTA is routed to irq 19 em0: bpf attached em0: Ethernet address: 00:10:f3:0c:5b:2a ioapic0: routing intpin 19 (PCI IRQ 19) to vector 49 em0: [FILTER] pci9: at device 0.1 (no driver attached) bringing em0 to upness seems to work fine: printf's inserted into subroutines em_handle_link and em_rxeof (if_em.c) freebsd70# ifconfig em0 up em0: Link is Down em_handle_link em_rxeof em_handle_link em_rxeof em0: Link is up 1000 Mbps Full Duplex freebsd70# ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=18b ether 00:10:f3:0c:5b:2a media: Ethernet autoselect (1000baseTX ) status: active interface stats: good packets increment but no em_rxeof/interrupts generated fifo is full after 85 received frames memory and missed packets are incrementing because they cant be stored in fifo (fifo exhausted) freebsd70# sysctl dev.em.0.stats=1 em0: Excessive collisions = 0 em0: Sequence errors = 0 em0: Defer count = 0 em0: Missed Packets = 144 em0: Receive No Buffers = 0 em0: Receive Length Errors = 0 em0: Receive errors = 0 em0: Crc errors = 0 em0: Alignment errors = 0 em0: Carrier extension errors = 0 em0: RX overruns = 0 em0: watchdog timeouts = 0 em0: XON Rcvd = 0 em0: XON Xmtd = 0 em0: XOFF Rcvd = 0 em0: XOFF Xmtd = 0 em0: Good Packets Rcvd = 85 em0: Good Packets Xmtd = 0 em0: TSO Contexts Xmtd = 0 em0: TSO Contexts Failed = 0 interface debug_info: output for registers RDBAH0/RDBAL0/RDLEN0/RDH0/RDT0/RXDCTL added RDH0/RDT0 do not increment after frame reception... cp. 6.1-RELENG: RDH0/RDT0 incremented after frame reception RDT0 is always 'RDH0 - 1' freebsd70# sysctl dev.em.0.debug_info=1 em0: Adapter hardware address = 0xc3b69a1c em0: CTRL = 0x81c0241 RCTL = 0x8002 em0: RDBAH0 = 0x0 RDBAL0 = 0x1458000 em0: RDLEN0 = 0x1000 RDH0 = 0x0 em0: RDT0 = 0xff RXDCTL = 0x10000 em0: Packet buffer = Tx=16k Rx=32k em0: Flow control watermarks high = 30720 low = 29220 em0: tx_int_delay = 66, tx_abs_int_delay = 66 em0: rx_int_delay = 0, rx_abs_int_delay = 66 em0: fifo workaround = 0, fifo_reset_count = 0 em0: hw tdh = 0, hw tdt = 0 em0: hw rdh = 0, hw rdt = 255 em0: Num Tx descriptors avail = 256 em0: Tx Descriptors not avail1 = 0 em0: Tx Descriptors not avail2 = 0 em0: Std mbuf failed = 0 em0: Std mbuf cluster failed = 0 em0: Driver dropped packets = 0 em0: Driver tx dma failure in encap = 0 From owner-freebsd-net@FreeBSD.ORG Tue Jul 17 11:15:17 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2913616A401 for ; Tue, 17 Jul 2007 11:15:17 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.freebsd.org (Postfix) with ESMTP id 003EC13C4C4 for ; Tue, 17 Jul 2007 11:15:16 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 17 Jul 2007 04:15:16 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAM9BnEarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,546,1175497200"; d="scan'208"; a="166946911:sNHT29501001" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6HBFGnN018164; Tue, 17 Jul 2007 04:15:16 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6HBFGA2009629; Tue, 17 Jul 2007 11:15:16 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 04:15:16 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 04:15:15 -0700 Message-ID: <469CA4F3.4080302@cisco.com> Date: Tue, 17 Jul 2007 07:16:03 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Healy , Mark Allman References: <469AF916.6090901@swin.edu.au> <469AFE80.2090304@swin.edu.au> <469B5069.6080706@cisco.com> <469C27CB.9090906@swin.edu.au> In-Reply-To: <469C27CB.9090906@swin.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2007 11:15:15.0796 (UTC) FILETIME=[C05C9940:01C7C863] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3177; t=1184670916; x=1185534916; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20Odd=20congestion=20window=20behaviour=20[=20was=3A=20 Draft=20email=20to=20freebsd-net=0A=20] |Sender:=20; bh=edIJDUbrGQQSkOJolBQK/SXWVbpQWUiXRIonyWjFCAI=; b=RX7dCyDReNfyDrcwP4QsrDdFDUYnn01vcHsRj3uCKyf/xZZAAECyWtuBDFAQkthXgkvz4vMr CFz31kbTIQ+2yXOYC1xrZCpc8lQxlf8dF4kohC92ns09wRCm/Fkjhxt+tgCU8vXnQNUsUBA5Cs 5uniAdxecAJ5GghQH80oesc68=; Authentication-Results: sj-dkim-1; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); Cc: freebsd-net@freebsd.org, Andrew Subject: Re: Odd congestion window behaviour [ was: Draft email to freebsd-net ] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 11:15:17 -0000 James Healy wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >>I.e. where we keep past connection state and use that >>as a reference for the initial cwnd. I asked Mark about >>this in the past.. and he said that his paper was >>mis-interpreted and this is incorrect behavior. If you >>have no connections up to a peer you should not use any >>past value for the cwnd... > > > So it's possible that the inital cwnd shouldn't be set by the hostcache > at all? > > If this was the case, does that mean we'd just use the rfc 3390 logic if > enabled, with fallback to the manual sysctl variables as a last resort? > IMO if you want to follow the true spirit of RFC3390 and RFC2581 then yes.. you should ONLY use RFC3390 (or 2581) to set your initial cwnd. I am adding Mark Allman on this to get his opinion.. Mark, here is your big chance to chime in on something that has had your name in comments in FreeBSD code for years... Basically let me referesh your memory in case you are not on net@freebsd.org (or you can go look at the thread). Currently FreeBSD will dig into its hostcache and set the cwnd of a new connection to the previous value with some constraints.. James posted these a fe days ago when noting funny behavior. I chimed in and said really IMO using the previous cwnd of old connections is NOT a good idea.. (I can see using the previous ssthresh.. but not cwnd).. and it is exactly why our SCTP implementation DOES NOT do this.. What do you think Mark (since your name is in the comments to justify this action).. R > James > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (FreeBSD) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGnCfL4oawkrbYo/kRAuRMAJ47fESbkRB076y7w4hUA25FJp8i+wCcCg13 > aMQJpkHxjy6RdWXVoGmHhX4= > =QYKp > -----END PGP SIGNATURE----- > > Swinburne University of Technology > CRICOS Provider Code: 00111D > > NOTICE > This e-mail and any attachments are confidential and intended only for the use of the addressee. They may contain information that is privileged or protected by copyright. If you are not the intended recipient, any dissemination, distribution, printing, copying or use is strictly prohibited. The University does not warrant that this e-mail and any attachments are secure and there is also a risk that it may be corrupted in transmission. It is your responsibility to check any attachments for viruses or defects before opening them. If you have received this transmission in error, please contact us on +61 3 9214 8000 and delete it immediately from your system. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. > > Please consider the environment before printing this email. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Tue Jul 17 12:24:50 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE14316A400 for ; Tue, 17 Jul 2007 12:24:50 +0000 (UTC) (envelope-from jhealy@groupwise.swin.edu.au) Received: from mailmonitor.cc.swin.edu.au (mailmonitor.cc.swin.edu.au [136.186.1.65]) by mx1.freebsd.org (Postfix) with ESMTP id 2113713C4B8 for ; Tue, 17 Jul 2007 12:24:49 +0000 (UTC) (envelope-from jhealy@groupwise.swin.edu.au) Received: from groupwise.swin.edu.au (Not Verified[136.186.3.218]) by mailmonitor.cc.swin.edu.au with MailMarshal (v6, 1, 4, 441) id ; Tue, 17 Jul 2007 22:04:32 +1000 Received: from INET-DOM-MTA by groupwise.swin.edu.au with Novell_GroupWise; Tue, 17 Jul 2007 22:04:32 +1000 Message-Id: <469D3CE1020000B70000F83B@groupwise.swin.edu.au> X-Mailer: Novell GroupWise Internet Agent 7.0.1 Date: Tue, 17 Jul 2007 22:04:17 +1000 From: "James Healy" To: , Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: andybrand@swin.edu.au Subject: Re: Odd congestion window behaviour [ was: Draft email to freebsd-net ] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 12:24:50 -0000 >>I.e. where we keep past connection state and use that >>as a reference for the initial cwnd. I asked Mark about >>this in the past.. and he said that his paper was >>mis-interpreted and this is incorrect behavior. If you >>have no connections up to a peer you should not use any >>past value for the cwnd... > > So it's possible that the inital cwnd shouldn't be set by the hostcache > at all? > > If this was the case, does that mean we'd just use the rfc 3390 logic if > enabled, with fallback to the manual sysctl variables as a last resort? I haven't tested it yet, but I just noticed that initial odd behaviour we observed looks like it's been fixed in tcp_input.c revisions 1.315 (MAIN) / 1.281.2.13 (RELENG_6). It ensures that tp->snd_wnd is initialised before being used to calculate the initial cwnd. The follow on question about setting cwnd from the hostcache still stands I guess, but at least with this fix we won't see transmission delays while the connection waits for a delayed ack timer to expire. James Swinburne University of Technology CRICOS Provider Code: 00111D NOTICE This e-mail and any attachments are confidential and intended only for the use of the addressee. They may contain information that is privileged or protected by copyright. If you are not the intended recipient, any dissemination, distribution, printing, copying or use is strictly prohibited. The University does not warrant that this e-mail and any attachments are secure and there is also a risk that it may be corrupted in transmission. It is your responsibility to check any attachments for viruses or defects before opening them. If you have received this transmission in error, please contact us on +61 3 9214 8000 and delete it immediately from your system. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. Please consider the environment before printing this email. From owner-freebsd-net@FreeBSD.ORG Tue Jul 17 14:18:03 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0420B16A401 for ; Tue, 17 Jul 2007 14:18:03 +0000 (UTC) (envelope-from raj@thenewfront.us) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by mx1.freebsd.org (Postfix) with ESMTP id C310113C4A6 for ; Tue, 17 Jul 2007 14:18:02 +0000 (UTC) (envelope-from raj@thenewfront.us) Received: by an-out-0708.google.com with SMTP id c14so359658anc for ; Tue, 17 Jul 2007 07:18:02 -0700 (PDT) Received: by 10.100.95.19 with SMTP id s19mr201596anb.1184680186173; Tue, 17 Jul 2007 06:49:46 -0700 (PDT) Received: from ?10.10.2.161? ( [67.90.137.89]) by mx.google.com with ESMTP id c39sm14222789anc.2007.07.17.06.49.42 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Jul 2007 06:49:42 -0700 (PDT) User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Tue, 17 Jul 2007 09:49:35 -0400 From: Raj To: Message-ID: In-Reply-To: <20070717120011.4E14D16A419@hub.freebsd.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Tcp checksum calculation wrong by 2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 14:18:03 -0000 Hi Folks, This problem is related to Mac OS X 10.3. Please accept my apologies for posting here , as I thought this is one avenue I could explore to get an answer and also OS X has some freebsd core too! I am looking at a driver code for OS X 10.3 where the checksum is being calculated on an inbound syn-ack. First by zeroing out the checksum, then calculating the checksum of the pseudo header and finally calculating the checksum. The checksum functions used are available in the xnu sources. Here is the snippet printf("tcplen =%x",tcplen); printf(" checksum Before=%x,\n",tcph->th_sum); tcph->th_sum=0; tcph->th_sum = in_pseudo(iph->ip_src.s_addr, iph->ip_dst.s_addr, htonl((iph->ip_p << 16) | (tcplen & 0xffff))); tcph->th_sum = in_cksum_skip(mbuf, packet_len, iph->ip_hl << 2); printf("final checksum tcph=%x,\n",tcph->th_sum); The final checksum is less by 2 than the original. Here is the sample output tcplen=26 checksum before =7182 final checksum=7180 tcplen=26 checksum before =2d87 final checksum=2d85 tcplen=26 checksum before =5ab0 final checksum=5aae I have also observed that the checksum is calculated correctly when the length of the tcp segment in the packet is 40. tcplen=40 checksum before =d1cf final checksum=d1cf tcplen=40 checksum before =e237 final checksum=e237 Can someone be kind enough to give me an idea on why I am getting the wrong checksum? TIA Raj From owner-freebsd-net@FreeBSD.ORG Tue Jul 17 15:55:20 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A33D716A401 for ; Tue, 17 Jul 2007 15:55:20 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with SMTP id 42B0713C4AC for ; Tue, 17 Jul 2007 15:55:20 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 443 invoked by uid 399); 17 Jul 2007 15:27:18 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 17 Jul 2007 15:27:18 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <469CDFD4.1090708@FreeBSD.org> Date: Tue, 17 Jul 2007 08:27:16 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.4 (X11/20070617) MIME-Version: 1.0 To: Raj References: In-Reply-To: X-Enigmail-Version: 0.95.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Tcp checksum calculation wrong by 2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 15:55:20 -0000 Raj wrote: > Hi Folks, > > This problem is related to Mac OS X 10.3. Sorry, this list isn't going to be able to help you with that. You should contact the Apple folks. Good luck, Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Tue Jul 17 16:17:42 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1B29016A401 for ; Tue, 17 Jul 2007 16:17:42 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.226]) by mx1.freebsd.org (Postfix) with ESMTP id BC3BE13C48D for ; Tue, 17 Jul 2007 16:17:41 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so1083729nzf for ; Tue, 17 Jul 2007 09:17:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XzDxvDk85TUciwno2DZ1oWp2pjUyJe9dWhWezL9aA7Rg2rk08SdODfYCJWI6RUKNNxWJpQBLOH2BJCll8VVKWVDbagCzMOckzlzGRiBqFMTf7NmaJJc0j4Rzy0eNRkuNX9x5KkGW1Wsoz/jXt6hvlQ7/KlkkXmEjI5/ZdUay5T0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eYhe4PSpruU0mZ4CRrzq6gbY2/vE97bXoHq38bki4dBi3gCKLmGlFz6EIwJX21y6TuqVYbLaKHl0ywV9LtFAFn0TjjLdZa9dzffM+TZfISUYUyb3GiNFtVeKyMPNwGSLryYK/Q6qBr4Nc2n+Mkmk4IVqkU/CIf+5TMZqO2TubQ4= Received: by 10.115.89.1 with SMTP id r1mr566342wal.1184689056271; Tue, 17 Jul 2007 09:17:36 -0700 (PDT) Received: by 10.114.103.14 with HTTP; Tue, 17 Jul 2007 09:17:36 -0700 (PDT) Message-ID: <2a41acea0707170917n56e35cfbyc6e0bca094bfa729@mail.gmail.com> Date: Tue, 17 Jul 2007 09:17:36 -0700 From: "Jack Vogel" To: freebsd-net@freebsd.org In-Reply-To: <20070717110156.GA37722@hbnnbsddev03.sharedtcs.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070717110156.GA37722@hbnnbsddev03.sharedtcs.net> Subject: Re: em(4)/82571eb: fifo not dma'ed to host memory X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 16:17:42 -0000 As an experiment, search in if_em.c for 'msix' look at the logic there. If the adapter is 82575 it will use msix, but the else clause has it use msi ONLY if its '>82571', change that to >=82571 and let's see if maybe using MSI will help you with your problems as I'm pretty confident its interrupt related. I had intended on making this change shortly anyway, my tests have shown the 571 to work fine this way. Let me know of the results. Jack On 7/17/07, Patrick Oeschger wrote: > bug description for 7.0-CURRENT - em(4) driver version 6.5.3 > - frame reception is not possible (missed packets counter incrementing) > - frame transmission is not possible (driver watchdog fires) > bug exists also on 6.2-RELENG - em(4) driver version 6.2.9 > bug does *not* exist on 6.1-RELENG - em(4) driver version 3.2.18 > > jack vogel told me that the i82571 can be tricky when having a bunch > of them - i have 8 such interfaces on the motherboard so i disabled > 7 of them with a modified em_probe (if_em.c) > running the driver on just one interface does not change the behaviour > > - init of the interface during verbose boot looks fine > - bringing the interface to upness looks fine too > - RDH0/RDT0 registers do *not* increment after frame reception > - frames suspected *not* getting dma'ed from fifo to host memory > - RX interrupt suspected *not* being sent to the driver > > see dmesg and debug ouput for futher details... > anybody having some experience with this issue? > any advice to track this further down? > thanks, pat > > > diff for em_probe subr to ensure that only one interface is init'ed: > > freebsd70# diff -u if_em.c.orig if_em.c > --- if_em.c.orig Tue Jul 17 11:18:18 2007 > +++ if_em.c Tue Jul 17 06:34:48 2007 > @@ -379,6 +379,10 @@ > > INIT_DEBUGOUT("em_probe: begin"); > > + // prevent init of all em(4) devices except pci9/0/0 > + if(pci_get_bus(dev) != 0x09 || pci_get_slot(dev) != 0x00 || > + pci_get_function(dev) != 0x00) > + return (ENXIO); > + > pci_vendor_id = pci_get_vendor(dev); > if (pci_vendor_id != EM_VENDOR_ID) > return (ENXIO); > > excerpt of verbose dmesg looks fine for em0: > > pcib9: irq 19 at device 11.0 on pci2 > pcib9: secondary bus 9 > pcib9: subordinate bus 9 > pcib9: I/O decode 0x6000-0x6fff > pcib9: memory decode 0xfd700000-0xfd7fffff > pcib9: prefetched decode 0xfce00000-0xfcefffff > pci9: on pcib9 > pci9: physical bus=9 > found-> vendor=0x8086, dev=0x105e, revid=0x06 > bus=9, slot=0, func=0 > class=02-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0, size 17, memory disabled > map[14]: type Memory, range 32, base 0, size 17, memory disabled > map[18]: type I/O Port, range 32, base 0, size 5, port disabled > found-> vendor=0x8086, dev=0x105e, revid=0x06 > bus=9, slot=0, func=1 > class=02-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0, size 17, memory disabled > map[14]: type Memory, range 32, base 0, size 17, memory disabled > map[18]: type I/O Port, range 32, base 0, size 5, port disabled > em0: > at device 0.0 on pci9 > pcib9: em0 requested memory range 0xfd700000-0xfd7fffff: good > pcib2: em0 requested memory range 0xfd700000-0xfd7fffff: good > pcib1: em0 requested memory range 0xfd700000-0xfd7fffff: good > em0: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at 0xfd700000 > pcib1: matched entry for 1.0.INTD > pcib1: slot 0 INTD hardwired to IRQ 19 > pcib2: slot 11 INTA is routed to irq 19 > pcib9: slot 0 INTA is routed to irq 19 > em0: bpf attached > em0: Ethernet address: 00:10:f3:0c:5b:2a > ioapic0: routing intpin 19 (PCI IRQ 19) to vector 49 > em0: [FILTER] > pci9: at device 0.1 (no driver attached) > > bringing em0 to upness seems to work fine: > printf's inserted into subroutines em_handle_link and em_rxeof (if_em.c) > > freebsd70# ifconfig em0 up > em0: Link is Down > em_handle_link > em_rxeof > em_handle_link > em_rxeof > em0: Link is up 1000 Mbps Full Duplex > freebsd70# ifconfig em0 > em0: flags=8843 metric 0 > mtu 1500 > options=18b > ether 00:10:f3:0c:5b:2a > media: Ethernet autoselect (1000baseTX ) > status: active > > interface stats: > good packets increment but no em_rxeof/interrupts generated > fifo is full after 85 received frames > memory and missed packets are incrementing because they cant be > stored in fifo (fifo exhausted) > > freebsd70# sysctl dev.em.0.stats=1 > em0: Excessive collisions = 0 > em0: Sequence errors = 0 > em0: Defer count = 0 > em0: Missed Packets = 144 > em0: Receive No Buffers = 0 > em0: Receive Length Errors = 0 > em0: Receive errors = 0 > em0: Crc errors = 0 > em0: Alignment errors = 0 > em0: Carrier extension errors = 0 > em0: RX overruns = 0 > em0: watchdog timeouts = 0 > em0: XON Rcvd = 0 > em0: XON Xmtd = 0 > em0: XOFF Rcvd = 0 > em0: XOFF Xmtd = 0 > em0: Good Packets Rcvd = 85 > em0: Good Packets Xmtd = 0 > em0: TSO Contexts Xmtd = 0 > em0: TSO Contexts Failed = 0 > > interface debug_info: > output for registers RDBAH0/RDBAL0/RDLEN0/RDH0/RDT0/RXDCTL added > RDH0/RDT0 do not increment after frame reception... > cp. 6.1-RELENG: RDH0/RDT0 incremented after frame reception > RDT0 is always 'RDH0 - 1' > > freebsd70# sysctl dev.em.0.debug_info=1 > em0: Adapter hardware address = 0xc3b69a1c > em0: CTRL = 0x81c0241 RCTL = 0x8002 > em0: RDBAH0 = 0x0 RDBAL0 = 0x1458000 > em0: RDLEN0 = 0x1000 RDH0 = 0x0 > em0: RDT0 = 0xff RXDCTL = 0x10000 > em0: Packet buffer = Tx=16k Rx=32k > em0: Flow control watermarks high = 30720 low = 29220 > em0: tx_int_delay = 66, tx_abs_int_delay = 66 > em0: rx_int_delay = 0, rx_abs_int_delay = 66 > em0: fifo workaround = 0, fifo_reset_count = 0 > em0: hw tdh = 0, hw tdt = 0 > em0: hw rdh = 0, hw rdt = 255 > em0: Num Tx descriptors avail = 256 > em0: Tx Descriptors not avail1 = 0 > em0: Tx Descriptors not avail2 = 0 > em0: Std mbuf failed = 0 > em0: Std mbuf cluster failed = 0 > em0: Driver dropped packets = 0 > em0: Driver tx dma failure in encap = 0 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Jul 17 18:50:12 2007 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 520C316A408 for ; Tue, 17 Jul 2007 18:50:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 29C3313C4BB for ; Tue, 17 Jul 2007 18:50:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l6HIoBlq017346 for ; Tue, 17 Jul 2007 18:50:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l6HIoBjE017345; Tue, 17 Jul 2007 18:50:11 GMT (envelope-from gnats) Date: Tue, 17 Jul 2007 18:50:11 GMT Message-Id: <200707171850.l6HIoBjE017345@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Jessica Mahoney Cc: Subject: Re: kern/109406: [ndis] Broadcom WLAN driver 4.100.15.5 doesn't work with Ndisgen X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jessica Mahoney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 18:50:12 -0000 The following reply was made to PR kern/109406; it has been noted by GNATS. From: Jessica Mahoney To: bug-followup@FreeBSD.org, darkvincentdude@yahoo.com Cc: Subject: Re: kern/109406: [ndis] Broadcom WLAN driver 4.100.15.5 doesn't work with Ndisgen Date: Tue, 17 Jul 2007 14:20:00 -0400 I noticed there is a working form of the function IoGetDeviceObjectPointer in NDISwrapper for linux. The function is located in ndiswrapper-1.47/driver/ntoskrnl_io.c, lines 935-961. It probably exists in other versions, too (most likely it does). ~J From owner-freebsd-net@FreeBSD.ORG Tue Jul 17 21:42:52 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B961516A400; Tue, 17 Jul 2007 21:42:52 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.freebsd.org (Postfix) with ESMTP id 44B9713C491; Tue, 17 Jul 2007 21:42:52 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.59.43] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1IAuok46hu-0004TK; Tue, 17 Jul 2007 23:42:51 +0200 From: Max Laier Organization: FreeBSD To: freebsd-arch@freebsd.org Date: Tue, 17 Jul 2007 23:42:14 +0200 User-Agent: KMail/1.9.7 References: <20070717131518.G1177@fledge.watson.org> In-Reply-To: <20070717131518.G1177@fledge.watson.org> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1196626.J7k12aMeaH"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200707172342.39082.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19wTlp8A33NdffBkuSCqDVAD9+nCn7iRlaGezK eaN4BkrpsX6hiwe8m+8VQDx2f86eCa9Ytt2Wkgxy/oHT2itbKU Pk3iYvWGauWY9V9jxacvY/MrZAJ8dPFw1jm9FBMSpQ= Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Robert Watson , freebsd-pf@freebsd.org Subject: Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 21:42:52 -0000 --nextPart1196626.J7k12aMeaH Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline [ Excess CC-list ... testers needed!!! ] On Tuesday 17 July 2007, Robert Watson wrote: > Dear all: > > This is a reminder e-mail that, in the very near future, Giant > compatibility shims for network protocols will be removed. <...> > The *only* remaining case I am aware of where removing debug.mpsafenet > presents an issue is credential-related firewall rules (uid, gid, > jail). I'm am currently in an active e-mail discussion with the > various firewall maintainers about how to address this issue; as the > implementations of these rules violate the global lock order, deadlocks > occur if debug.mpsafenet isn't set to 1, which causes Giant to act as a > guard lock preventing parallel lock acquisition in the firewall.=20 > Hopefully we will have this resolved, in some form, soon. What we really need right now, is real understanding of the problem (if=20 there even is any). So we would like to ask everybody who is able to -=20 to stress test user/group rules (in pf) or uid/gid/jail rules (in ipfw)=20 with debug.mpsafenet=3D1 It is normal that (in an WITNESS enabled kernel)= =20 you get a LOR similar to 14-17 and 32 from [1]. Everything different to=20 those should be reported. If you indeed get a deadlock, please let us know and provide as much=20 debugging information as you can. DDB's "ps", "show locks", "show=20 alllocks" would be perfect, but detailed information how to repeat would=20 be a good start to already. Thanks a lot! If you are unable to provoke a deadlock, please let us know= =20 as well. Include a few setup details (ruleset, SMP, special sysctl=20 settings ...) so we can look for patterns. [1] http://sources.zabbadoz.net/freebsd/lor.html =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1196626.J7k12aMeaH Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGnTfPXyyEoT62BG0RAlyQAJ4gRB+txS34yl7wZUd4WEF1fNI32ACfecPR prtWaB/DFI+ykloZIk8nin4= =Mvwf -----END PGP SIGNATURE----- --nextPart1196626.J7k12aMeaH-- From owner-freebsd-net@FreeBSD.ORG Tue Jul 17 21:52:07 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9F08E16A407 for ; Tue, 17 Jul 2007 21:52:07 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outK.internet-mail-service.net (outK.internet-mail-service.net [216.240.47.234]) by mx1.freebsd.org (Postfix) with ESMTP id 7EE6F13C47E for ; Tue, 17 Jul 2007 21:52:07 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 17 Jul 2007 14:52:06 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 45AB8125AE6; Tue, 17 Jul 2007 14:52:06 -0700 (PDT) Message-ID: <469D3A23.5000809@elischer.org> Date: Tue, 17 Jul 2007 14:52:35 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Max Laier References: <20070717131518.G1177@fledge.watson.org> <200707172342.39082.max@love2party.net> In-Reply-To: <200707172342.39082.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Robert Watson , freebsd-pf@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 21:52:07 -0000 Max Laier wrote: > [ Excess CC-list ... testers needed!!! ] > > On Tuesday 17 July 2007, Robert Watson wrote: >> Dear all: >> >> This is a reminder e-mail that, in the very near future, Giant >> compatibility shims for network protocols will be removed. > > <...> > >> The *only* remaining case I am aware of where removing debug.mpsafenet >> presents an issue is credential-related firewall rules (uid, gid, >> jail). I'm am currently in an active e-mail discussion with the >> various firewall maintainers about how to address this issue; as the >> implementations of these rules violate the global lock order, deadlocks >> occur if debug.mpsafenet isn't set to 1, which causes Giant to act as a >> guard lock preventing parallel lock acquisition in the firewall. >> Hopefully we will have this resolved, in some form, soon. > > What we really need right now, is real understanding of the problem (if > there even is any). So we would like to ask everybody who is able to - > to stress test user/group rules (in pf) or uid/gid/jail rules (in ipfw) > with debug.mpsafenet=1 It is normal that (in an WITNESS enabled kernel) > you get a LOR similar to 14-17 and 32 from [1]. Everything different to > those should be reported. > > If you indeed get a deadlock, please let us know and provide as much > debugging information as you can. DDB's "ps", "show locks", "show > alllocks" would be perfect, but detailed information how to repeat would > be a good start to already. > > Thanks a lot! If you are unable to provoke a deadlock, please let us know > as well. Include a few setup details (ruleset, SMP, special sysctl > settings ...) so we can look for patterns. I've not seen a deadlock, only LOR warnings. > > [1] http://sources.zabbadoz.net/freebsd/lor.html > From owner-freebsd-net@FreeBSD.ORG Tue Jul 17 23:21:30 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 42AF316A407 for ; Tue, 17 Jul 2007 23:21:30 +0000 (UTC) (envelope-from prvs=julian=71160acf2@ironport.com) Received: from c60-outbound.ironport.com (c60-outbound.ironport.com [63.251.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 2B18213C4CC for ; Tue, 17 Jul 2007 23:21:30 +0000 (UTC) (envelope-from prvs=julian=71160acf2@ironport.com) Received: from jelischer-laptop.sfo.ironport.com (HELO julian-mac.elischer.org) ([10.251.22.38]) by c60-outbound.ironport.com with ESMTP; 17 Jul 2007 16:10:56 -0700 Message-ID: <469D4C9D.7090302@ironport.com> Date: Tue, 17 Jul 2007 16:11:25 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: FreeBSD Net Content-Type: multipart/mixed; boundary="------------000700090307030408070507" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Wierd networking. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 23:21:30 -0000 This is a multi-part message in MIME format. --------------000700090307030408070507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have been looking at the following snippet of packets (under FreeBSD 6.1). This makes IE7 fail (but not IE6) with a generic error. We see lots of strange things here.. (like, why does the RST go to a different sequence number?) What we are having problems with is: What SHOULD the server be doing in response to the extra 2 bytes it receives after it has sent the FIN? I would LIKE to be able to make this work, but I don't personally have the influence to fix IE7 so I'm left to do what I can on the server (port 3128) end. The FIN from the server is generated when the server closes the socket. --------------000700090307030408070507 Content-Type: application/octet-stream; x-mac-type="0"; x-mac-creator="0"; name="IE7.pcap" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="IE7.pcap" obLD1AACAAQAAAAAAAAAAAAA//8AAAABRpwaWQAEyiIAAAA2AAAANgAEI7WpKwAODKoSBAgA RQAAKIouQABABtQbrBwPUgr7Fh0MOARh4nZh4V3EjTJQEH143KAAAEacGlkABMqLAAAAjgAA AI4ADgyqEgQABCO1qZQIAEUAAICSf0AAfAaPcgr7Fh2sHA9SBGEMOF3EjTLidmHhUBj//+wx AABydE9yZGVyPTAmdWNMb3dlclBhZ2VyJTNBdHh0R290bz0mdWNVcHBlclBhZ2VyJTNBYnRu TmV4dC54PTMmdWNVcHBlclBhZ2VyJTNBYnRuTmV4dC55PTEzRpwaWQAEyp8AAAA2AAAANgAE I7WpKwAODKoSBAgARQAAKIovQABABtQarBwPUgr7Fh0MOARh4nZh4V3EjYpQEILU3KAAAEac GlkABMrYAAAF6gAABeoABCO1qSsADgyqEgQIAEUABdyKMEAAQAbOZawcD1IK+xYdDDgEYeJ2 YeFdxI2KUBCDLOJUAABIVFRQLzEuMCA0MDcgUHJveHkgQXV0aGVudGljYXRpb24gUmVxdWly ZWQNCk1pbWUtVmVyc2lvbjogMS4wDQpEYXRlOiBUdWUsIDE3IEp1bCAyMDA3IDAxOjI0OjQx IEdNVA0KQ29udGVudC1UeXBlOiB0ZXh0L2h0bWwNClByb3h5LUF1dGhlbnRpY2F0ZTogTlRM TQ0KUHJveHktQXV0aGVudGljYXRlOiBOZWdvdGlhdGUNClByb3h5LUF1dGhlbnRpY2F0ZTog QmFzaWMgcmVhbG09Iklyb25Qb3J0IFdlYiBTZWN1cml0eSBBcHBsaWFuY2UiDQpQcm94eS1D b25uZWN0aW9uOiBjbG9zZQ0KQ29udGVudC1MZW5ndGg6IDE0NDINCg0KPCFET0NUWVBFIEhU TUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFsLy9FTiIKImh0 dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+CjxodG1sPgo8aGVhZD4KPG1l dGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9aXNvLTg4NTktMSI+Cjx0aXRsZT5Ob3RpZmljYXRpb246IFByb3h5IEF1dGhvcml6YXRp b24gUmVxdWlyZWQ8L3RpdGxlPgo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPgo8IS0tCmJvZHkg ewogICAgbWFyZ2luLWxlZnQ6IDIlOwogICAgbWFyZ2luLXJpZ2h0OiAyJTsKfQpwIHsKICAg IGZvbnQtZmFtaWx5OiB2ZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOwog ICAgZm9udC1zaXplOiAxMnB4OwogICAgdG9wOiAwcHg7CiAgICBtYXJnaW4tdG9wOiA2cHg7 CiAgICBtYXJnaW4tYm90dG9tOiA2cHg7Cn0KdGQgewogICAgZm9udC1mYW1pbHk6IHZlcmRh bmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7CiAgICBmb250LXNpemU6IDEycHg7 CiAgICB0b3A6IDBweDsKfQouY29kZSB7CiAgICBmb250LWZhbWlseTogY291cmllcjsKICAg IGZvbnQtc2l6ZTogMTJweDsKICAgIHRvcDogMHB4Owp9CmgxIHsKICAgIGZvbnQtZmFtaWx5 OiB2ZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOwogICAgZm9udC1zaXpl OiAxNnB4OwogICAgbWFyZ2luLXRvcDogMjRweDsKICAgIG1hcmdpbi1ib3R0b206IDhweDsK fQpociB7CiAgICBtYXJnaW4tdG9wOiAycHg7CiAgICBtYXJnaW4tYm90dG9tOiAycHg7Cn0K LS0+Cjwvc3R5bGU+CjwvaGVhZD4KCjxib2R5PgoKPGgxPlRoaXMgUGFnZSBDYW5ub3QgQmUg RGlzcGxheWVkPC9oMT4KPGhyPgoKPHA+CkF1dGhlbnRpY2F0aW9uIGlzIHJlcXVpcmVkIHRv IGFjY2VzcyB0aGUgSW50ZXJuZXQgdXNpbmcgdGhpcyBzeXN0ZW0uCkEgdmFsaWQgdXNlciBJ RCBhbmQgcGFzc3dvcmQgbXVzdCBiZSBlbnRlcmVkIHdoZW4gcHJvbXB0ZWQuCjwvcD4KCgoK PHA+CklmIHlvdSBoYXZlIHF1ZXN0aW9ucywgbmVlZCBhc3Npc3RhbmNlIHdpdGggeW91ciBs b2dpbgppbmZvcm1hdGlvbiwgb3IgZmVlbCB0aGlzIGlzIGFuIGVycm9yLCBwbGVhc2UgY29u dGFjdAp5b3VyIGNvcnBvckacGlkABMrgAAABTgAAAU4ABCO1qSsADgyqEgQIAEUAAUCKMUAA QAbTAKwcD1IK+xYdDDgEYeJ2Z5VdxI2KUBiDLN24AABhdGUgbmV0d29yayBhZG1pbmlzdHJh dG9yIAphbmQgcHJvdmlkZSB0aGUgY29kZXMgc2hvd24gYmVsb3cuCjwvcD4KCjxocj4KPHRh YmxlPgogIDx0ciB2YWxpZ249InRvcCI+CiAgICA8dGQgdmFsaWduPSJ0b3AiIHdpZHRoPSIx MCUiPk5vdGlmaWNhdGlvbiZuYnNwO2NvZGVzOiZuYnNwOzwvdGQ+CiAgICA8dGQgdmFsaWdu PSJ0b3AiIGNsYXNzPSJjb2RlIiB3aWR0aD0iOTAlIj4oMSwgUFJPWFlfQVVUSF9SRVFVSVJF RCk8L3RkPgogIDwvdHI+CjwvdGFibGU+Cgo8L2JvZHk+CjwvaHRtbD4KRpwaWQAEywYAAAA2 AAAANgAEI7WpKwAODKoSBAgARQAAKIoyQABABtQXrBwPUgr7Fh0MOARh4nZorV3EjYpQEYMs 3KAAAEacGlkABM14AAAAPAAAADwADgyqEgQABCO1qZQIAEUAACqSgEAAfAaPxwr7Fh2sHA9S BGEMOF3EjYridmHhUBj//4X6AAANCgAAAABGnBpZAATNjwAAADYAAAA2AAQjtakrAA4MqhIE CABFAAAoijNAAEAG1BasHA9SCvsWHQw4BGHidmHhAAAAAFAEAADcoAAARpwaWQAEz20AAAA8 AAAAPAAODKoSBAAEI7WplAgARQAAKJKCQAB8Bo/HCvsWHawcD1IEYQw4XcSNjOJ2Z5VQEP// jVgAAAAAAAAAAEacGlkABM9+AAAANgAAADYABCO1qSsADgyqEgQIAEUAACiKNEAAQAbUFawc D1IK+xYdDDgEYeJ2Z5UAAAAAUAQAANygAABGnBpZAATP6QAAADwAAAA8AA4MqhIEAAQjtamU CABFAAAokoNAAHwGj8YK+xYdrBwPUgRhDDhdxI2M4nZorlAQ/ueNVwAAAAAAAAAARpwaWQAE z/gAAAA2AAAANgAEI7WpKwAODKoSBAgARQAAKIo1QABABtQUrBwPUgr7Fh0MOARh4nZorgAA AABQBAAA3KAAAEacGlkABNDjAAAAPAAAADwADgyqEgQABCO1qZQIAEUAACiShEAAfAaPxQr7 Fh2sHA9SBGEMOF3EjYzidmiuUBD+541XAAAAAAAAAABGnBpZAATQ5gAAADwAAAA8AA4MqhIE AAQjtamUCABFAAAokoVAAHwGj8QK+xYdrBwPUgRhDDhdxI2M4nZorlAQ/ueNVwAAAAAAAAAA RpwaWQAE0PoAAAA2AAAANgAEI7WpKwAODKoSBAgARQAAKIo2QABABtQTrBwPUgr7Fh0MOARh 4nZorgAAAABQBAAA3KAAAEacGlkABNECAAAANgAAADYABCO1qSsADgyqEgQIAEUAACiKN0AA QAbUEqwcD1IK+xYdDDgEYeJ2aK4AAAAAUAQAANygAABGnBpZAATRYAAAADwAAAA8AA4MqhIE AAQjtamUCABFAAAokoZAAHwGj8MK+xYdrBwPUgRhDDhdxI2M4nZorlAQ/ueNVwAAAAAAAAAA RpwaWQAE0XkAAAA2AAAANgAEI7WpKwAODKoSBAgARQAAKIo4QABABtQRrBwPUgr7Fh0MOARh 4nZorgAAAABQBAAA3KAAAA== --------------000700090307030408070507-- From owner-freebsd-net@FreeBSD.ORG Tue Jul 17 23:24:10 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF74016A405 for ; Tue, 17 Jul 2007 23:24:10 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outN.internet-mail-service.net (outN.internet-mail-service.net [216.240.47.237]) by mx1.freebsd.org (Postfix) with ESMTP id D9FAF13C471 for ; Tue, 17 Jul 2007 23:24:10 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 17 Jul 2007 16:24:10 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 0E63C125A25; Tue, 17 Jul 2007 16:24:10 -0700 (PDT) Message-ID: <469D4FB6.9040609@elischer.org> Date: Tue, 17 Jul 2007 16:24:38 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Julian Elischer References: <469D4C9D.7090302@ironport.com> In-Reply-To: <469D4C9D.7090302@ironport.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: Wierd networking. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 23:24:11 -0000 Julian Elischer wrote: > I have been looking at the following snippet of packets (under FreeBSD > 6.1). > > This makes IE7 fail (but not IE6) with a generic error. > > We see lots of strange things here.. (like, why does the RST > go to a different sequence number?) figured that one out... it's using the latest ACK value from the client.. > > What we are having problems with is: > > What SHOULD the server be doing in response to the extra 2 bytes > it receives after it has sent the FIN? > > I would LIKE to be able to make this work, but I don't personally > have the influence to fix IE7 so I'm left to do what I can on the server > (port 3128) end. > > The FIN from the server is generated when the server closes the socket. note: IE7 never sends a FIN. (IE6 does) > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Jul 17 23:47:32 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6955E16A402 for ; Tue, 17 Jul 2007 23:47:32 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by mx1.freebsd.org (Postfix) with ESMTP id 5078613C4BB for ; Tue, 17 Jul 2007 23:47:32 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out4.apple.com (Postfix) with ESMTP id 38A60C47863; Tue, 17 Jul 2007 16:47:32 -0700 (PDT) Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id 1D42E29C002; Tue, 17 Jul 2007 16:47:32 -0700 (PDT) X-AuditID: 11807123-a5f3ebb000000b34-05-469d55137015 Received: from [17.214.13.96] (cswiger1.apple.com [17.214.13.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay5.apple.com (Apple SCV relay) with ESMTP id EA0D930400C; Tue, 17 Jul 2007 16:47:31 -0700 (PDT) In-Reply-To: <469D4FB6.9040609@elischer.org> References: <469D4C9D.7090302@ironport.com> <469D4FB6.9040609@elischer.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3DBBD4E3-ABEA-451A-8E6A-02E9CBAD6A37@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Tue, 17 Jul 2007 16:47:30 -0700 To: Julian Elischer X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: Julian Elischer , FreeBSD Net Subject: Re: Wierd networking. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 23:47:32 -0000 [ I'm not sure which email address I should use when you reply to yourself using a different addy. :-) ] On Jul 17, 2007, at 4:24 PM, Julian Elischer wrote: > Julian Elischer wrote: >> I have been looking at the following snippet of packets (under >> FreeBSD 6.1). >> This makes IE7 fail (but not IE6) with a generic error. >> We see lots of strange things here.. (like, why does the RST >> go to a different sequence number?) > > figured that one out... it's using the latest ACK value from the > client.. Sort of; the 2-byte push from 10.251.22.29.1121 ACKs the sequence # of the Squid box before it sends out the 1460-byte packet (ie, 3799409121): % tcpdump -nS -r IE7.pcap reading from file IE7.pcap, link-type EN10MB (Ethernet) 18:24:41.313890 IP 172.28.15.82.3128 > 10.251.22.29.1121: . ack 1573162290 win 32120 18:24:41.313995 IP 10.251.22.29.1121 > 172.28.15.82.3128: P 1573162290:1573162378(88) ack 3799409121 win 65535 18:24:41.314015 IP 172.28.15.82.3128 > 10.251.22.29.1121: . ack 1573162378 win 33492 18:24:41.314072 IP 172.28.15.82.3128 > 10.251.22.29.1121: . 3799409121:3799410581(1460) ack 1573162378 win 33580 18:24:41.314080 IP 172.28.15.82.3128 > 10.251.22.29.1121: P 3799410581:3799410861(280) ack 1573162378 win 33580 18:24:41.314118 IP 172.28.15.82.3128 > 10.251.22.29.1121: F 3799410861:3799410861(0) ack 1573162378 win 33580 ...at this point, the client should have received the above packets and ACK for 3799410862 to include the FIN. 18:24:41.314744 IP 10.251.22.29.1121 > 172.28.15.82.3128: P 1573162378:1573162380(2) ack 3799409121 win 65535 ...instead it sends an ACK for earlier traffic. The Squid box should be in FIN-WAIT-1 and simply ignore this as a dup ACK, rather than sending an RST: 18:24:41.314767 IP 172.28.15.82.3128 > 10.251.22.29.1121: R 3799409121:3799409121(0) win 0 18:24:41.315245 IP 10.251.22.29.1121 > 172.28.15.82.3128: . ack 3799410581 win 65535 Here the client ACK's the 1460-byte packet, and gets another RST. 18:24:41.315262 IP 172.28.15.82.3128 > 10.251.22.29.1121: R 3799410581:3799410581(0) win 0 18:24:41.315369 IP 10.251.22.29.1121 > 172.28.15.82.3128: . ack 3799410862 win 65255 ...and here the client ACK's the 280-byte packet plus the packet with the FIN; it should be sending a FIN here to move both sides to CLOSING state... 18:24:41.315384 IP 172.28.15.82.3128 > 10.251.22.29.1121: R 3799410862:3799410862(0) win 0 18:24:41.315619 IP 10.251.22.29.1121 > 172.28.15.82.3128: . ack 3799410862 win 65255 18:24:41.315622 IP 10.251.22.29.1121 > 172.28.15.82.3128: . ack 3799410862 win 65255 18:24:41.315642 IP 172.28.15.82.3128 > 10.251.22.29.1121: R 3799410862:3799410862(0) win 0 18:24:41.315650 IP 172.28.15.82.3128 > 10.251.22.29.1121: R 3799410862:3799410862(0) win 0 18:24:41.315744 IP 10.251.22.29.1121 > 172.28.15.82.3128: . ack 3799410862 win 65255 18:24:41.315769 IP 172.28.15.82.3128 > 10.251.22.29.1121: R 3799410862:3799410862(0) win 0 ...and the rest of this is the client sending ACKs, and the Squid box generating spurious resets each time, when it should be in TIME-WAIT for 2 * MSL. >> What we are having problems with is: >> What SHOULD the server be doing in response to the extra 2 bytes >> it receives after it has sent the FIN? >> I would LIKE to be able to make this work, but I don't personally >> have the influence to fix IE7 so I'm left to do what I can on the >> server (port 3128) end. >> The FIN from the server is generated when the server closes the >> socket. > > note: IE7 never sends a FIN. (IE6 does) That seems very bizzare; does the version of IE really affect the TCP/ IP networking layer? -- -Chuck From owner-freebsd-net@FreeBSD.ORG Wed Jul 18 04:36:22 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D92C16A403 for ; Wed, 18 Jul 2007 04:36:22 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by mx1.freebsd.org (Postfix) with ESMTP id 5D24413C4B6 for ; Wed, 18 Jul 2007 04:36:22 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so88973waf for ; Tue, 17 Jul 2007 21:36:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=rDUrxYjsk3dtJ1ENtm8BvvYkU5r3TukGDJhjOMUWmvp3GimhL3fPL5tvNpS8aboLe+spScMrZbkgValtsNYWuwJS90iTS3Y7k09s973Q6dLFxo58kcY5EN5b5Mz6ShUHhh4HACy6x6Jj9fsp95PP1Y8FJAZEEkdxRcOLp14kH70= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=ApurPpjiTvplDBxnB6tQPtEH/j8D1V4vaUoqaJ1bblvPoOW8LzFPt3RIQNbfGZS1kVpl0THERlOTMqBXy51Gb1KCXBBVUTtxeKJorZ1QCZavnjWUstAUTSoBDlJg/DePjVF4h4/FmwR27xBQphWg69X2uQDb41fUjpKcOZpThCk= Received: by 10.114.89.1 with SMTP id m1mr1097790wab.1184733382132; Tue, 17 Jul 2007 21:36:22 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id m40sm670804waf.2007.07.17.21.36.19 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Jul 2007 21:36:21 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l6I4aEUY039144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2007 13:36:14 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l6I4aBNl039143; Wed, 18 Jul 2007 13:36:11 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 18 Jul 2007 13:36:11 +0900 From: Pyun YongHyeon To: "Bjoern A. Zeeb" Message-ID: <20070718043611.GD37935@cdnetworks.co.kr> References: <4678896b.1cef600a.1a79.7312@mx.google.com> <20070620100441.E98813@maildrop.int.zabbadoz.net> <4ab61a80706200336l49f16764t1d95c61f0dd323e5@mail.gmail.com> <20070716181837.Y31116@maildrop.int.zabbadoz.net> <4ab61a80707161233m11e49f2brac162a882f4ebbd7@mail.gmail.com> <20070716201218.U31116@maildrop.int.zabbadoz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070716201218.U31116@maildrop.int.zabbadoz.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: soekris/sis tx checksum problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 04:36:22 -0000 On Mon, Jul 16, 2007 at 08:14:14PM +0000, Bjoern A. Zeeb wrote: > On Mon, 16 Jul 2007, David Cornejo wrote: > > >I eventually reinstalled the OS from a recent snapshot then updated it > >to the latest CURRENT and it works fine now :-( > > Hmm I am using CURRENT from today and I culd see the issue. > > I set sysctl net.inet.udp.checksum=0 to get things working temporary. > > In addition I am backing out a change from May and shall see if that > helps. > I've looked over sis_encap() and it seems that there is potential bug for descriptor wrap-around/shortage in bus_dmamap_load loop. After checking for necessity of m_defrag(9) it blindly assumes it has enough available Tx descriptors to send the packet. What if it sill have more fragments than currently available Tx desciptors after calling m_defrag()? Unfortunately bus_dma(9) changes for sis(4) requires real hardware and I don't have it... If I had it I would have fixed it to run it on sparc64. > Did you have/do you have any private patches in your tree? > -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Wed Jul 18 05:52:38 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 87A6316A403 for ; Wed, 18 Jul 2007 05:52:38 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 3A4B213C47E for ; Wed, 18 Jul 2007 05:52:37 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=Ajcse88nOovqpgqg48BeXEf7iAG7Ddvdd23B7PTe65v+of8VP5YXzyQa+U9+IAjGMGLeFFhO2kt5CCpheZw7V8eBKNnwqLBK84ohHp47m4b8dz/DtWATumiowxLt5erJCdqB/grEsdwdUT2II1uMxEQIaxCgg8T+RZSZ5sdyYOs=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1IB2Sf-000GWO-Vj; Wed, 18 Jul 2007 09:52:34 +0400 Date: Wed, 18 Jul 2007 09:52:28 +0400 From: Eygene Ryabinkin To: Chuck Swiger Message-ID: <20070718055228.GA4053@void.codelabs.ru> References: <469D4C9D.7090302@ironport.com> <469D4FB6.9040609@elischer.org> <3DBBD4E3-ABEA-451A-8E6A-02E9CBAD6A37@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <3DBBD4E3-ABEA-451A-8E6A-02E9CBAD6A37@mac.com> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.0 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: Julian Elischer , FreeBSD Net , Julian Elischer Subject: Re: Wierd networking. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 05:52:38 -0000 Chuck, Julian, good day. Tue, Jul 17, 2007 at 04:47:30PM -0700, Chuck Swiger wrote: > % tcpdump -nS -r IE7.pcap > reading from file IE7.pcap, link-type EN10MB (Ethernet) > 18:24:41.313890 IP 172.28.15.82.3128 > 10.251.22.29.1121: . ack 1573162290 win > 32120 > 18:24:41.313995 IP 10.251.22.29.1121 > 172.28.15.82.3128: P > 1573162290:1573162378(88) ack 3799409121 win 65535 > 18:24:41.314015 IP 172.28.15.82.3128 > 10.251.22.29.1121: . ack 1573162378 win > 33492 > 18:24:41.314072 IP 172.28.15.82.3128 > 10.251.22.29.1121: . > 3799409121:3799410581(1460) ack 1573162378 win 33580 > 18:24:41.314080 IP 172.28.15.82.3128 > 10.251.22.29.1121: P > 3799410581:3799410861(280) ack 1573162378 win 33580 > 18:24:41.314118 IP 172.28.15.82.3128 > 10.251.22.29.1121: F > 3799410861:3799410861(0) ack 1573162378 win 33580 > > ...at this point, the client should have received the above packets and ACK for > 3799410862 to include the FIN. > > 18:24:41.314744 IP 10.251.22.29.1121 > 172.28.15.82.3128: P > 1573162378:1573162380(2) ack 3799409121 win 65535 > > ...instead it sends an ACK for earlier traffic. The Squid box should be in > FIN-WAIT-1 and simply ignore this as a dup ACK, rather than sending an RST: Seems like it is the effect of the SS_NOFDREF check in the netinet/tcp_input.c, at least it is present in the rev. 1.281.2.5. See the post http://lists.freebsd.org/pipermail/freebsd-current/2007-July/074837.html I believe it discuisses the same problem, but for -CURRENT. In short, Squid child closes the descriptor, so connection is present in the TCP/IP stack only. And SS_NOFDREF check provokes RST and invokes tcp_close(). -- Eygene From owner-freebsd-net@FreeBSD.ORG Wed Jul 18 06:39:55 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 33C7716A405 for ; Wed, 18 Jul 2007 06:39:55 +0000 (UTC) (envelope-from paketix@bluewin.ch) Received: from mx27.bluewin.ch (mx27.bluewin.ch [195.186.18.40]) by mx1.freebsd.org (Postfix) with ESMTP id E835313C4B5 for ; Wed, 18 Jul 2007 06:39:54 +0000 (UTC) (envelope-from paketix@bluewin.ch) Received: from hbnnbsddev03.sharedtcs.net (213.3.8.216) by mx27.bluewin.ch (Bluewin 7.3.122) id 46641D9A049BDC32 for freebsd-net@freebsd.org; Wed, 18 Jul 2007 06:39:53 +0000 Received: from hbnnbsddev03.sharedtcs.net (localhost.sharedtcs.net [127.0.0.1]) by hbnnbsddev03.sharedtcs.net (8.13.8/8.13.8) with ESMTP id l6I6hPFr040897 for ; Wed, 18 Jul 2007 08:43:25 +0200 (CEST) (envelope-from tbeoepa1@hbnnbsddev03.sharedtcs.net) Received: (from tbeoepa1@localhost) by hbnnbsddev03.sharedtcs.net (8.13.8/8.13.8/Submit) id l6I6c13j040870 for freebsd-net@freebsd.org; Wed, 18 Jul 2007 08:38:01 +0200 (CEST) (envelope-from tbeoepa1) Date: Wed, 18 Jul 2007 08:38:01 +0200 From: Patrick Oeschger To: freebsd-net@freebsd.org Message-ID: <20070718063801.GA40653@hbnnbsddev03.sharedtcs.net> Mail-Followup-To: freebsd-net@freebsd.org References: <20070717110156.GA37722@hbnnbsddev03.sharedtcs.net> <2a41acea0707170917n56e35cfbyc6e0bca094bfa729@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a41acea0707170917n56e35cfbyc6e0bca094bfa729@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Subject: Re: em(4)/82571eb: fifo not dma'ed to host memory X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 06:39:55 -0000 thanks for your feedback jack - i tried the MSI stuff as first task this morning the interface init'ed without a problem and did not complain about MSI what i like most is that no IRQ is assigned now, everything seems to get handled in a TASKQ (IRQs were quite weird sometimes when having a bunch of interfaces...) but now the bad news: even with MSI it is not possible to recv any frames what makes me curious is, that the head pointer for receive fifo is *not* counting up after receiving a frame (good_packets counter incrementing) as far as i understand the 82571EB chipset manual, recv head counter inc is done in hardware after receiving a good_packet and having dma'ed it to host memory from if_em.c/em_process_receive_interrupts: * This routine executes in interrupt context. It replenishes * the mbufs in the descriptor and sends data which has been * dma'ed into host memory to upper layer. i did a quick test to check this on 6.1-RELENG by inserting a return at the top of em_process_receive_interrupts (see diff) register RDH0 is still incrementing for each good_packet received - even without receive interrupts being processed at the driver level freebsd61# sysctl dev.em.0.debug_info=1 dev.em.0.debug_iemnfo: 0:-1 Adapter hardware address = 0xc4b7c928 em0: CTRL = 0x81c0241 RCTL = 0x8002 em0: RDBAH0 = 0x0 RDBAL0 = 0x3e0ff000 em0: RDLEN0 = 0x1000 RDH0 = 0x3 em0: RDT0 = 0xff RXDCTL = 0x10000 ...so IMHO this increment (and also dma transfer to host memory) is done in hardware - RDH0 is not counting up when running under 7.0-CURRENT... erroneous init of chipset? anyone else running 7.0-CURRENT on a 82571EB pci express chipset? TIA for any help on this pat details for dmesg/if_stats/diff: pcib9: irq 19 at device 11.0 on pci2 pcib9: secondary bus 9 pcib9: subordinate bus 9 pcib9: I/O decode 0x6000-0x6fff pcib9: memory decode 0xfd700000-0xfd7fffff pcib9: prefetched decode 0xfce00000-0xfcefffff pci9: on pcib9 pci9: physical bus=9 found-> vendor=0x8086, dev=0x105e, revid=0x06 bus=9, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0, size 17, memory disabled map[14]: type Memory, range 32, base 0, size 17, memory disabled map[18]: type I/O Port, range 32, base 0, size 5, port disabled found-> vendor=0x8086, dev=0x105e, revid=0x06 bus=9, slot=0, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0, size 17, memory disabled map[14]: type Memory, range 32, base 0, size 17, memory disabled map[18]: type I/O Port, range 32, base 0, size 5, port disabled em0: at device 0.0 on pci9 pcib9: em0 requested memory range 0xfd700000-0xfd7fffff: good pcib2: em0 requested memory range 0xfd700000-0xfd7fffff: good pcib1: em0 requested memory range 0xfd700000-0xfd7fffff: good em0: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at 0xfd700000 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to vector 49 em0: using IRQ 256 for MSI em0: bpf attached em0: Ethernet address: 00:10:f3:0c:5b:2a em0: [FILTER] pci9: at device 0.1 (no driver attached) freebsd61# diff -u sys/dev/em/if_em.c.orig sys/dev/em/if_em.c --- sys/dev/em/if_em.c.orig Wed Jul 18 07:32:53 2007 +++ sys/dev/em/if_em.c Wed Jul 18 07:48:42 2007 @@ -277,6 +277,11 @@ INIT_DEBUGOUT("em_probe: begin"); + // prevent init of all em(4) devices except pci9/0/0 + if(pci_get_bus(dev) != 0x09 || pci_get_slot(dev) != 0x00 || + pci_get_function(dev) != 0x00) + return (ENXIO); + pci_vendor_id = pci_get_vendor(dev); if (pci_vendor_id != EM_VENDOR_ID) return(ENXIO); @@ -2906,6 +2911,8 @@ u_int8_t eop = 0; u_int16_t len, desc_len, prev_len_adj; int i; + + return; /* Pointer to the receive descriptor being examined. */ struct em_rx_desc *current_desc; On Tue, Jul 17, 2007 at 09:17:36AM -0700, Jack Vogel wrote: > As an experiment, search in if_em.c for 'msix' look at the logic there. > If the adapter is 82575 it will use msix, but the else clause has it > use msi ONLY if its '>82571', change that to >=82571 and let's > see if maybe using MSI will help you with your problems as I'm > pretty confident its interrupt related. > > I had intended on making this change shortly anyway, my tests > have shown the 571 to work fine this way. > > Let me know of the results. > > Jack From owner-freebsd-net@FreeBSD.ORG Wed Jul 18 06:57:35 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E31F016A402 for ; Wed, 18 Jul 2007 06:57:35 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5382613C49D for ; Wed, 18 Jul 2007 06:57:35 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 63744 invoked from network); 18 Jul 2007 06:54:16 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 18 Jul 2007 06:54:16 -0000 Message-ID: <469DB9EB.3090703@freebsd.org> Date: Wed, 18 Jul 2007 08:57:47 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Eygene Ryabinkin References: <469D4C9D.7090302@ironport.com> <469D4FB6.9040609@elischer.org> <3DBBD4E3-ABEA-451A-8E6A-02E9CBAD6A37@mac.com> <20070718055228.GA4053@void.codelabs.ru> In-Reply-To: <20070718055228.GA4053@void.codelabs.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Elischer , FreeBSD Net , Julian Elischer Subject: Re: Wierd networking. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 06:57:36 -0000 Eygene Ryabinkin wrote: > Chuck, Julian, good day. > > Tue, Jul 17, 2007 at 04:47:30PM -0700, Chuck Swiger wrote: >> % tcpdump -nS -r IE7.pcap >> reading from file IE7.pcap, link-type EN10MB (Ethernet) >> 18:24:41.313890 IP 172.28.15.82.3128 > 10.251.22.29.1121: . ack 1573162290 win >> 32120 >> 18:24:41.313995 IP 10.251.22.29.1121 > 172.28.15.82.3128: P >> 1573162290:1573162378(88) ack 3799409121 win 65535 >> 18:24:41.314015 IP 172.28.15.82.3128 > 10.251.22.29.1121: . ack 1573162378 win >> 33492 >> 18:24:41.314072 IP 172.28.15.82.3128 > 10.251.22.29.1121: . >> 3799409121:3799410581(1460) ack 1573162378 win 33580 >> 18:24:41.314080 IP 172.28.15.82.3128 > 10.251.22.29.1121: P >> 3799410581:3799410861(280) ack 1573162378 win 33580 >> 18:24:41.314118 IP 172.28.15.82.3128 > 10.251.22.29.1121: F >> 3799410861:3799410861(0) ack 1573162378 win 33580 >> >> ...at this point, the client should have received the above packets and ACK for >> 3799410862 to include the FIN. >> >> 18:24:41.314744 IP 10.251.22.29.1121 > 172.28.15.82.3128: P >> 1573162378:1573162380(2) ack 3799409121 win 65535 >> >> ...instead it sends an ACK for earlier traffic. The Squid box should be in >> FIN-WAIT-1 and simply ignore this as a dup ACK, rather than sending an RST: > > Seems like it is the effect of the SS_NOFDREF check in the > netinet/tcp_input.c, at least it is present in the rev. 1.281.2.5. > > See the post > http://lists.freebsd.org/pipermail/freebsd-current/2007-July/074837.html > > I believe it discuisses the same problem, but for -CURRENT. In > short, Squid child closes the descriptor, so connection is present > in the TCP/IP stack only. And SS_NOFDREF check provokes RST and > invokes tcp_close(). I think your analysis is correct. Have to find out who to deal properly with a closed socket before the TCP is closed as well. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Jul 18 07:24:00 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B25D216A402; Wed, 18 Jul 2007 07:24:00 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 6311813C471; Wed, 18 Jul 2007 07:24:00 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=AEeEBqPBJVT5QbrbzoUOngE5RPGTgCb5QiSNkL04NK1PW02zdK52ahQJIBW9IrE0vdDl5sw95LcAfDlUG0jcu2uhsq3NsUiqUXBLaNBWAWaLGvg6PhBlRQpGuwHXMYVRdP4bDzzL/LO/Xy3mwM8RGafS2J5TWWDiuJLdZABij/k=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1IB3t7-000H2H-JQ; Wed, 18 Jul 2007 11:23:57 +0400 Date: Wed, 18 Jul 2007 11:23:52 +0400 From: Eygene Ryabinkin To: Andre Oppermann Message-ID: <20070718072352.GE4053@void.codelabs.ru> References: <469D4C9D.7090302@ironport.com> <469D4FB6.9040609@elischer.org> <3DBBD4E3-ABEA-451A-8E6A-02E9CBAD6A37@mac.com> <20070718055228.GA4053@void.codelabs.ru> <469DB9EB.3090703@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <469DB9EB.3090703@freebsd.org> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.0 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: Julian Elischer , FreeBSD Net , Julian Elischer Subject: Re: Wierd networking. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 07:24:00 -0000 Andre, good day. Wed, Jul 18, 2007 at 08:57:47AM +0200, Andre Oppermann wrote: > >Seems like it is the effect of the SS_NOFDREF check in the > >netinet/tcp_input.c, at least it is present in the rev. 1.281.2.5. > >See the post > > http://lists.freebsd.org/pipermail/freebsd-current/2007-July/074837.html > >I believe it discuisses the same problem, but for -CURRENT. In > >short, Squid child closes the descriptor, so connection is present > >in the TCP/IP stack only. And SS_NOFDREF check provokes RST and > >invokes tcp_close(). > > I think your analysis is correct. Have to find out who to deal properly > with a closed socket before the TCP is closed as well. OK, please, drop a letter when you will produce some patch or will find out how to deal with this -- I am keen to test and/or discuiss. Thank you! -- Eygene From owner-freebsd-net@FreeBSD.ORG Wed Jul 18 13:05:06 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3CC3616A400 for ; Wed, 18 Jul 2007 13:05:06 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: from smtpout06.prod.mesa1.secureserver.net (smtpout06-04.prod.mesa1.secureserver.net [64.202.165.227]) by mx1.freebsd.org (Postfix) with SMTP id 02C4413C494 for ; Wed, 18 Jul 2007 13:05:05 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: (qmail 18243 invoked from network); 18 Jul 2007 13:05:05 -0000 Received: from unknown (24.144.77.243) by smtpout06-04.prod.mesa1.secureserver.net (64.202.165.227) with ESMTP; 18 Jul 2007 13:05:05 -0000 Message-ID: <469E0FFF.8070802@seclark.us> Date: Wed, 18 Jul 2007 09:05:03 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; m18) Gecko/20010110 Netscape6/6.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: karels@karels.net References: <200707150237.l6F2bAgZ011098@redrock.karels.net> In-Reply-To: <200707150237.l6F2bAgZ011098@redrock.karels.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, Robert Watson , Julian Elischer , Bill Moran , Sten Daniel Soersdal Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Clark@seclark.us List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 13:05:06 -0000 Mike Karels wrote: >>A related change that should probably be discussed if we want to think more >>about asymmetry in maximum transmission unit is this one: >> >> > > > >> ---------------------------- >> revision 1.98 >> date: 2006/06/26 17:54:53; author: andre; state: Exp; lines: +2 -0 >> In syncache_respond() do not reply with a MSS that is larger than what >> the peer announced to us but make it at least tcp_minmss in size. >> >> > > > >> Sponsored by: TCP/IP Optimization Fundraise 2005 >> ---------------------------- >> >> > > > >>In this change, we cap the advertised MSS in SYN/ACK to the received >>advertised MSS, which presumably avoids an extra PMTU round trip if jumbograms >>are enabled on the receiving endpoint. However, it also prevents use of >>larger packet sizes if asymmetric MTU is supported. I think I suggested after >>this was committed that we at least add an administrative twiddle to >>enable/disable this mode of operation, but don't see one in there currently. >>Does the Secure Computing scenario use TCP in this way, and is the potential >>win in avoiding a PMTU round-trip worth disallowing asymmetric MSS at the TCP >>layer? >> >> > >In our case, TCP isn't aware of the MRU, and bases its MSS on the MTU values. >However, I don't see any reason for TCP to cap the MSS at the received MSS. >If the other end doesn't want to receive more than 1024 bytes, that's no >reason to refuse to accept more. > > Mike > > > So was any decision reached on this issue - will FreeBSD changed to accept a packet on an interface that is larger than the mtu on that interface? Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-net@FreeBSD.ORG Wed Jul 18 18:24:33 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B15016A417; Wed, 18 Jul 2007 18:24:33 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.179]) by mx1.freebsd.org (Postfix) with ESMTP id 077E613C4C2; Wed, 18 Jul 2007 18:24:32 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.59.43] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML31I-1IBEBx3FFg-0003x5; Wed, 18 Jul 2007 20:24:12 +0200 From: Max Laier Organization: FreeBSD To: Scott Bennett Date: Wed, 18 Jul 2007 20:23:54 +0200 User-Agent: KMail/1.9.7 References: <200707181807.l6II7twY010844@mp.cs.niu.edu> In-Reply-To: <200707181807.l6II7twY010844@mp.cs.niu.edu> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1451727.14gfUS2vFd"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200707182024.01380.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19eEl6lKuqv1UQWwT/FMzwvOz3QKempCkasCpi xbgx61bo0c8LT5Zj2DylW+nXy8093v1JOaWfCN28LX6oMkiDqe rgheioHifripFD2X5i1DAdw2H1h1/lSLffOeOXQSKA= Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Robert Watson Subject: Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 18:24:33 -0000 --nextPart1451727.14gfUS2vFd Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 18 July 2007, Scott Bennett wrote: > [Cc: list trimmed a bit more --SB] > On Tue, 17 Jul 2007 23:42:14 +0200 Max Laier > > >[ Excess CC-list ... testers needed!!! ] > > > >On Tuesday 17 July 2007, Robert Watson wrote: > > I missed Robert Watson's start of thread, so I'm jumping in here > with a question. > > >> Dear all: > >> > >> This is a reminder e-mail that, in the very near future, Giant > >> compatibility shims for network protocols will be removed. > > How, if at all, will this affect qemu users? qemu exits unless > AIO is present in the kernel (or aio.ko has been kldload-ed). In > FreeBSD 6.2, AIO results in a warning message at boot time that says > AIO is not MPSAFE and that therefore the networking stack will take a > deep performance hit. This has already been answered in the original thread. AIO is mpsafe as=20 of Tue May 9 00:10:11 2006 (vfs_aio.c, rev 1.223). =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1451727.14gfUS2vFd Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGnlrBXyyEoT62BG0RApVWAJ9SH9zZZo717QOuwMq+zd6dELlKWQCfeJwP h+qN45bwng93dAoptkOzJwQ= =PF1h -----END PGP SIGNATURE----- --nextPart1451727.14gfUS2vFd-- From owner-freebsd-net@FreeBSD.ORG Wed Jul 18 19:06:43 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EAAAC16A405; Wed, 18 Jul 2007 19:06:43 +0000 (UTC) (envelope-from bennett@cs.niu.edu) Received: from mp.cs.niu.edu (mp.cs.niu.edu [131.156.68.41]) by mx1.freebsd.org (Postfix) with ESMTP id B78B113C4C3; Wed, 18 Jul 2007 19:06:43 +0000 (UTC) (envelope-from bennett@cs.niu.edu) Received: from mp.cs.niu.edu (bennett@localhost [127.0.0.1]) by mp.cs.niu.edu (8.14.1/8.14.1) with ESMTP id l6II7tu7010845; Wed, 18 Jul 2007 13:07:55 -0500 (CDT) Date: Wed, 18 Jul 2007 13:07:55 -0500 (CDT) From: Scott Bennett Message-Id: <200707181807.l6II7twY010844@mp.cs.niu.edu> To: freebsd-net@freebsd.org, Max Laier Cc: freebsd-current@freebsd.org, Robert Watson Subject: Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 19:06:44 -0000 [Cc: list trimmed a bit more --SB] On Tue, 17 Jul 2007 23:42:14 +0200 Max Laier >[ Excess CC-list ... testers needed!!! ] > >On Tuesday 17 July 2007, Robert Watson wrote: I missed Robert Watson's start of thread, so I'm jumping in here with a question. >> Dear all: >> >> This is a reminder e-mail that, in the very near future, Giant >> compatibility shims for network protocols will be removed. > How, if at all, will this affect qemu users? qemu exits unless AIO is present in the kernel (or aio.ko has been kldload-ed). In FreeBSD 6.2, AIO results in a warning message at boot time that says AIO is not MPSAFE and that therefore the networking stack will take a deep performance hit. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * ********************************************************************** From owner-freebsd-net@FreeBSD.ORG Wed Jul 18 19:40:35 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A854316A404 for ; Wed, 18 Jul 2007 19:40:35 +0000 (UTC) (envelope-from prvs=julian=7129fe7e3@ironport.com) Received: from c60-outbound.ironport.com (c60-outbound.ironport.com [63.251.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 8FC0913C481 for ; Wed, 18 Jul 2007 19:40:35 +0000 (UTC) (envelope-from prvs=julian=7129fe7e3@ironport.com) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.64]) by c60-outbound.ironport.com with ESMTP; 18 Jul 2007 12:11:45 -0700 Message-ID: <469E660F.8000109@ironport.com> Date: Wed, 18 Jul 2007 12:12:15 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Eygene Ryabinkin References: <469D4C9D.7090302@ironport.com> <469D4FB6.9040609@elischer.org> <3DBBD4E3-ABEA-451A-8E6A-02E9CBAD6A37@mac.com> <20070718055228.GA4053@void.codelabs.ru> In-Reply-To: <20070718055228.GA4053@void.codelabs.ru> Content-Type: multipart/mixed; boundary="------------070601040006030604020807" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Net , Julian Elischer Subject: Re: Wierd networking. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 19:40:35 -0000 This is a multi-part message in MIME format. --------------070601040006030604020807 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Eygene Ryabinkin wrote: > Chuck, Julian, good day. > > Tue, Jul 17, 2007 at 04:47:30PM -0700, Chuck Swiger wrote: > >> % tcpdump -nS -r IE7.pcap >> reading from file IE7.pcap, link-type EN10MB (Ethernet) >> 18:24:41.313890 IP 172.28.15.82.3128 > 10.251.22.29.1121: . ack 1573162290 win >> 32120 >> 18:24:41.313995 IP 10.251.22.29.1121 > 172.28.15.82.3128: P >> 1573162290:1573162378(88) ack 3799409121 win 65535 >> 18:24:41.314015 IP 172.28.15.82.3128 > 10.251.22.29.1121: . ack 1573162378 win >> 33492 >> 18:24:41.314072 IP 172.28.15.82.3128 > 10.251.22.29.1121: . >> 3799409121:3799410581(1460) ack 1573162378 win 33580 >> 18:24:41.314080 IP 172.28.15.82.3128 > 10.251.22.29.1121: P >> 3799410581:3799410861(280) ack 1573162378 win 33580 >> 18:24:41.314118 IP 172.28.15.82.3128 > 10.251.22.29.1121: F >> 3799410861:3799410861(0) ack 1573162378 win 33580 >> >> ...at this point, the client should have received the above packets and ACK for >> 3799410862 to include the FIN. >> >> 18:24:41.314744 IP 10.251.22.29.1121 > 172.28.15.82.3128: P >> 1573162378:1573162380(2) ack 3799409121 win 65535 >> >> ...instead it sends an ACK for earlier traffic. The Squid box should be in >> FIN-WAIT-1 and simply ignore this as a dup ACK, rather than sending an RST: >> > > Seems like it is the effect of the SS_NOFDREF check in the > netinet/tcp_input.c, at least it is present in the rev. 1.281.2.5. > > See the post > http://lists.freebsd.org/pipermail/freebsd-current/2007-July/074837.html > That makes perfect sense.. thankyou. I will check this avenue of inquiry. possibly we should do a shutdown() and let the file descriptor exist for a few seconds. > I believe it discuisses the same problem, but for -CURRENT. In > short, Squid child closes the descriptor, so connection is present > in the TCP/IP stack only. And SS_NOFDREF check provokes RST and > invokes tcp_close(). > --------------070601040006030604020807-- From owner-freebsd-net@FreeBSD.ORG Wed Jul 18 19:48:22 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 98F7716A405; Wed, 18 Jul 2007 19:48:22 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5F27413C49D; Wed, 18 Jul 2007 19:48:22 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id A0FF646B38; Wed, 18 Jul 2007 15:48:21 -0400 (EDT) Date: Wed, 18 Jul 2007 20:48:21 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Scott Bennett In-Reply-To: <200707181807.l6II7twY010844@mp.cs.niu.edu> Message-ID: <20070718204552.G1096@fledge.watson.org> References: <200707181807.l6II7twY010844@mp.cs.niu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Max Laier Subject: Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 19:48:22 -0000 On Wed, 18 Jul 2007, Scott Bennett wrote: > [Cc: list trimmed a bit more --SB] > On Tue, 17 Jul 2007 23:42:14 +0200 Max Laier > >> [ Excess CC-list ... testers needed!!! ] >> >> On Tuesday 17 July 2007, Robert Watson wrote: > > I missed Robert Watson's start of thread, so I'm jumping in here > with a question. > >>> This is a reminder e-mail that, in the very near future, Giant >>> compatibility shims for network protocols will be removed. > > How, if at all, will this affect qemu users? qemu exits unless AIO is > present in the kernel (or aio.ko has been kldload-ed). In FreeBSD 6.2, AIO > results in a warning message at boot time that says AIO is not MPSAFE and > that therefore the networking stack will take a deep performance hit. Per several earlier e-mails in the thread, AIO is MPSAFE in FreeBSD 7.0 and, as such, unaffected by this change. As a result, I would expect that applications depending on AIO should now perform significantly better (but have done no measurement in this area). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Wed Jul 18 19:54:48 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD6CC16A414; Wed, 18 Jul 2007 19:54:48 +0000 (UTC) (envelope-from bennett@cs.niu.edu) Received: from mp.cs.niu.edu (mp.cs.niu.edu [131.156.145.41]) by mx1.freebsd.org (Postfix) with ESMTP id 6A93813C494; Wed, 18 Jul 2007 19:54:41 +0000 (UTC) (envelope-from bennett@cs.niu.edu) Received: from mp.cs.niu.edu (bennett@localhost [127.0.0.1]) by mp.cs.niu.edu (8.14.1/8.14.1) with ESMTP id l6IJsAAY013573; Wed, 18 Jul 2007 14:54:10 -0500 (CDT) Date: Wed, 18 Jul 2007 14:54:10 -0500 (CDT) From: Scott Bennett Message-Id: <200707181954.l6IJsAvN013572@mp.cs.niu.edu> To: rwatson@FreeBSD.org Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, max@love2party.net Subject: Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 19:54:49 -0000 On Wed, 18 Jul 2007 20:48:21 +0100 (BST) Robert Watson wrote: >On Wed, 18 Jul 2007, Scott Bennett wrote: > >> [Cc: list trimmed a bit more --SB] >> On Tue, 17 Jul 2007 23:42:14 +0200 Max Laier >> >>> [ Excess CC-list ... testers needed!!! ] >>> >>> On Tuesday 17 July 2007, Robert Watson wrote: >> >> I missed Robert Watson's start of thread, so I'm jumping in here >> with a question. >> >>>> This is a reminder e-mail that, in the very near future, Giant >>>> compatibility shims for network protocols will be removed. >> >> How, if at all, will this affect qemu users? qemu exits unless AIO is >> present in the kernel (or aio.ko has been kldload-ed). In FreeBSD 6.2, AIO >> results in a warning message at boot time that says AIO is not MPSAFE and >> that therefore the networking stack will take a deep performance hit. > >Per several earlier e-mails in the thread, AIO is MPSAFE in FreeBSD 7.0 and, >as such, unaffected by this change. As a result, I would expect that >applications depending on AIO should now perform significantly better (but >have done no measurement in this area). > Great! Thanks for this news. My apologies for missing the previous messages. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * ********************************************************************** From owner-freebsd-net@FreeBSD.ORG Wed Jul 18 21:03:18 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 720EC16A403 for ; Wed, 18 Jul 2007 21:03:18 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from smtp813.mail.ird.yahoo.com (smtp813.mail.ird.yahoo.com [217.146.188.73]) by mx1.freebsd.org (Postfix) with SMTP id 94DA413C48D for ; Wed, 18 Jul 2007 21:03:17 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: (qmail 57888 invoked from network); 18 Jul 2007 21:03:15 -0000 Received: from unknown (HELO ?192.168.1.2?) (thomasjudge@btinternet.com@86.140.28.215 with plain) by smtp813.mail.ird.yahoo.com with SMTP; 18 Jul 2007 21:03:15 -0000 X-YMail-OSG: QOsJfKcVM1nL2gb58Aa6zIjd3Gwwn8F6hmaC8XhHsPuZe_hq Message-ID: <469E8E5F.9000707@tomjudge.com> Date: Wed, 18 Jul 2007 23:04:15 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Stephen.Clark@seclark.us References: <200707150237.l6F2bAgZ011098@redrock.karels.net> <469E0FFF.8070802@seclark.us> In-Reply-To: <469E0FFF.8070802@seclark.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bill Moran , freebsd-net@FreeBSD.org, karels@karels.net, Robert Watson , Julian Elischer , Sten Daniel Soersdal Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 21:03:18 -0000 Stephen Clark wrote: > Mike Karels wrote: > >>> A related change that should probably be discussed if we want to >>> think more about asymmetry in maximum transmission unit is this one: >>> >> >> >> >>> ---------------------------- >>> revision 1.98 >>> date: 2006/06/26 17:54:53; author: andre; state: Exp; lines: +2 -0 >>> In syncache_respond() do not reply with a MSS that is larger than what >>> the peer announced to us but make it at least tcp_minmss in size. >>> >> >> >> >>> Sponsored by: TCP/IP Optimization Fundraise 2005 >>> ---------------------------- >>> >> >> >> >>> In this change, we cap the advertised MSS in SYN/ACK to the received >>> advertised MSS, which presumably avoids an extra PMTU round trip if >>> jumbograms are enabled on the receiving endpoint. However, it also >>> prevents use of larger packet sizes if asymmetric MTU is supported. >>> I think I suggested after this was committed that we at least add an >>> administrative twiddle to enable/disable this mode of operation, but >>> don't see one in there currently. Does the Secure Computing scenario >>> use TCP in this way, and is the potential win in avoiding a PMTU >>> round-trip worth disallowing asymmetric MSS at the TCP layer? >>> >> >> In our case, TCP isn't aware of the MRU, and bases its MSS on the MTU >> values. >> However, I don't see any reason for TCP to cap the MSS at the received >> MSS. >> If the other end doesn't want to receive more than 1024 bytes, that's no >> reason to refuse to accept more. >> >> Mike >> >> >> > So was any decision reached on this issue - will FreeBSD changed to > accept a packet on an > interface that is larger than the mtu on that interface? > > Steve > There are also things to consider such as if a GigE card is connected to a GigE device (switch/card etc) and the card supports jumbo frames should the MRU be set to the max jumbo receive size for the card? This could cause confusion when people plug jumbo capable devices in with hardware limitations making the MRU lower than other devices on the network. Just some thoughts. Tom From owner-freebsd-net@FreeBSD.ORG Wed Jul 18 22:42:28 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E664116A406 for ; Wed, 18 Jul 2007 22:42:28 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.239]) by mx1.freebsd.org (Postfix) with ESMTP id A50F313C4C5 for ; Wed, 18 Jul 2007 22:42:28 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so283429nzf for ; Wed, 18 Jul 2007 15:42:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fnOEQPee70bvm7bPEf+gcryUnhp3WmsFt6BhpJ8saQHgy4fdVe1Czum0OusOUkEnrtqVZmg34X1a8b1ZQ/5CEqjLipDs6dygTcsdPImGNwtc7g68hpmSiMZl/xKc0xtIxj87jNUQMR2eYePRsXRFQ8jnir7tVfc4VXxxhX3YU3E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OMM9+yDMcDbJmj/oC+TDc5/YsB56kOgGHGjPw7NaCh7n1j9+9+igtg3BbIhbt45k3fMrrtMAIgVkK9+OK/oH+oZJr5cKKiTjtm+Kr5QODB4FNFDurQvrEEPcDmfGHbUY7MEFmB45XgGGVBQGgN9BatZS3eZQHy6rz1HU4m8ltK8= Received: by 10.115.108.1 with SMTP id k1mr1955280wam.1184798547438; Wed, 18 Jul 2007 15:42:27 -0700 (PDT) Received: by 10.114.103.14 with HTTP; Wed, 18 Jul 2007 15:42:27 -0700 (PDT) Message-ID: <2a41acea0707181542q23d36733o339448ad86f480cb@mail.gmail.com> Date: Wed, 18 Jul 2007 15:42:27 -0700 From: "Jack Vogel" To: freebsd-net , "FreeBSD Current" In-Reply-To: <2a41acea0707181152r4c662b00tf1be7b6b4dce74f1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0707181152r4c662b00tf1be7b6b4dce74f1@mail.gmail.com> Cc: Subject: 10G and socket alloc failure X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 22:42:29 -0000 While testing out the ixgbe driver we've observed this failure in the stack code, here is the info: The test engineer is using iperf, typically with 16 threads. If the driver is using either legacy or MSI interrupts we will see broken pipes, in dmesg its due to sonewconn() failing in syncache_socket(). Whats interesting is that when I have multiple RX queues configured and using MSI/X this doesnt happen, at least not very often. It does not seem to hurt performance horribly, iperf just spawns another thread, but I was wondering if there is some underlying tuneable I dont know about that would stop this from happening?? And any theory about why it doesnt happen with multiple queues? Jack From owner-freebsd-net@FreeBSD.ORG Thu Jul 19 01:30:43 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7DDE716A401 for ; Thu, 19 Jul 2007 01:30:43 +0000 (UTC) (envelope-from karels@redrock.karels.net) Received: from redrock.karels.net (redrock.karels.net [206.196.45.2]) by mx1.freebsd.org (Postfix) with ESMTP id 247CE13C474 for ; Thu, 19 Jul 2007 01:30:42 +0000 (UTC) (envelope-from karels@redrock.karels.net) Received: from redrock.karels.net (localhost.karels.net [127.0.0.1]) by redrock.karels.net (8.13.8/8.13.6) with ESMTP id l6J1UfS4027169; Wed, 18 Jul 2007 20:30:41 -0500 (CDT) (envelope-from karels@redrock.karels.net) Message-Id: <200707190130.l6J1UfS4027169@redrock.karels.net> To: Tom Judge From: Mike Karels In-reply-to: Your message of Wed, 18 Jul 2007 23:04:15 +0100. <469E8E5F.9000707@tomjudge.com> Date: Wed, 18 Jul 2007 20:30:41 -0500 Sender: karels@karels.net Cc: freebsd-net@freebsd.org Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: karels@karels.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 01:30:43 -0000 > There are also things to consider such as if a GigE card is connected to > a GigE device (switch/card etc) and the card supports jumbo frames > should the MRU be set to the max jumbo receive size for the card? This > could cause confusion when people plug jumbo capable devices in with > hardware limitations making the MRU lower than other devices on the network. Although we don't have an MRU explicitly, we don't enable reception of jumbo frames without administrator action. There is an IFCAP_JUMBO_MTU flag defined, but not previously used as far as I know. We added the ability to set that flag with ifconfig, which enables reception of jumbo frames without changing the MTU. Then, in ether_input, we accept any packet that a NIC sees fit to receive. Mike From owner-freebsd-net@FreeBSD.ORG Thu Jul 19 03:01:14 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EB2E216A401 for ; Thu, 19 Jul 2007 03:01:14 +0000 (UTC) (envelope-from dmehler26@woh.rr.com) Received: from ms-smtp-01.ohiordc.rr.com (ms-smtp-01.ohiordc.rr.com [65.24.5.135]) by mx1.freebsd.org (Postfix) with ESMTP id 9A9AA13C4A8 for ; Thu, 19 Jul 2007 03:01:14 +0000 (UTC) (envelope-from dmehler26@woh.rr.com) Received: from satellite (cpe-71-64-129-15.woh.res.rr.com [71.64.129.15]) by ms-smtp-01.ohiordc.rr.com (8.13.6/8.13.6) with SMTP id l6J31CmW003541 for ; Wed, 18 Jul 2007 23:01:12 -0400 (EDT) Message-ID: <000701c7c9b1$1061aea0$0200a8c0@satellite> From: "Dave" To: Date: Wed, 18 Jul 2007 23:01:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: freebsd6 utilities and proxy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 03:01:15 -0000 Hello, I've got a FreeBSD 6.2 machine now behind a squid nontransparent authenticating proxy. The proxy use to be transparent and didn't require authentication, those requirements now changed, so it now utilizes a dedicated ip and basic authentication. This is fine for the machine it's on, but for machines behind it this presents a problem. They run freshclam for virus updating, csup or portsnap, fetch, and portupgrade and maybe others not sure if i remembered them all. Is there a simple way i can configure this box to deal with the new proxy? Thanks. Dave. From owner-freebsd-net@FreeBSD.ORG Thu Jul 19 03:38:40 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DECA616A402 for ; Thu, 19 Jul 2007 03:38:40 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6393F13C4C9 for ; Thu, 19 Jul 2007 03:38:40 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from ednmsw510.dsto.defence.gov.au (ednmsw510.dsto.defence.gov.au [131.185.68.11]) by digger1.defence.gov.au (8.13.8/8.13.8) with ESMTP id l6J37ALq009309 for ; Thu, 19 Jul 2007 12:37:10 +0930 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw510.dsto.defence.gov.au (Clearswift SMTPRS 5.2.9) with ESMTP id for ; Thu, 19 Jul 2007 12:47:35 +0930 Received: from obelix.dsto.defence.gov.au ([203.6.60.208]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 12:47:35 +0930 Received: from obelix.dsto.defence.gov.au (localhost [127.0.0.1]) by obelix.dsto.defence.gov.au (8.14.1/8.14.1) with ESMTP id l6J3H84U072275 for ; Thu, 19 Jul 2007 11:17:08 +0800 (WST) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by obelix.dsto.defence.gov.au (8.14.1/8.14.1/Submit) id l6J3H8It072274 for freebsd-net@freebsd.org; Thu, 19 Jul 2007 11:17:08 +0800 (WST) (envelope-from wilkinsa) Date: Thu, 19 Jul 2007 11:17:08 +0800 From: "Wilkinson, Alex" To: freebsd-net@freebsd.org Message-ID: <20070719031708.GE67480@obelix.dsto.defence.gov.au> Mail-Followup-To: freebsd-net@freebsd.org References: <000701c7c9b1$1061aea0$0200a8c0@satellite> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <000701c7c9b1$1061aea0$0200a8c0@satellite> Organisation: Defence Science Technology Organisation User-Agent: Mutt/1.5.16 (2007-06-09) X-OriginalArrivalTime: 19 Jul 2007 03:17:35.0558 (UTC) FILETIME=[5A5AD660:01C7C9B3] X-TM-AS-Product-Ver: SMEX-7.0.0.1526-5.0.1021-15306.000 X-TM-AS-Result: No--4.032600-0.000000-31 Content-Transfer-Encoding: 7bit Subject: Re: freebsd6 utilities and proxy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 03:38:41 -0000 0n Wed, Jul 18, 2007 at 11:01:11PM -0400, Dave wrote: >I've got a FreeBSD 6.2 machine now behind a squid nontransparent >authenticating proxy. The proxy use to be transparent and didn't require >authentication, those requirements now changed, so it now utilizes a >dedicated ip and basic authentication. This is fine for the machine it's on, >but for machines behind it this presents a problem. They run freshclam for >virus updating, csup or portsnap, fetch, and portupgrade and maybe others >not sure if i remembered them all. Is there a simple way i can configure >this box to deal with the new proxy? Environment variables: HTTP_PROXY= HTTP_PROXY_AUTH= FTP_PROXY= -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-net@FreeBSD.ORG Thu Jul 19 03:46:17 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 906F216A407 for ; Thu, 19 Jul 2007 03:46:17 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outN.internet-mail-service.net (outN.internet-mail-service.net [216.240.47.237]) by mx1.freebsd.org (Postfix) with ESMTP id 7B1F213C494 for ; Thu, 19 Jul 2007 03:46:17 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Wed, 18 Jul 2007 20:46:17 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id B6C86125ADC; Wed, 18 Jul 2007 20:46:16 -0700 (PDT) Message-ID: <469EDEA7.9000606@elischer.org> Date: Wed, 18 Jul 2007 20:46:47 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: karels@karels.net References: <200707190130.l6J1UfS4027169@redrock.karels.net> In-Reply-To: <200707190130.l6J1UfS4027169@redrock.karels.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tom Judge , freebsd-net@freebsd.org Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 03:46:17 -0000 Mike Karels wrote: >> There are also things to consider such as if a GigE card is connected to >> a GigE device (switch/card etc) and the card supports jumbo frames >> should the MRU be set to the max jumbo receive size for the card? This >> could cause confusion when people plug jumbo capable devices in with >> hardware limitations making the MRU lower than other devices on the network. > > Although we don't have an MRU explicitly, we don't enable reception > of jumbo frames without administrator action. There is an IFCAP_JUMBO_MTU > flag defined, but not previously used as far as I know. We added the > ability to set that flag with ifconfig, which enables reception of > jumbo frames without changing the MTU. Then, in ether_input, we accept > any packet that a NIC sees fit to receive. for what values of "we"? > > Mike > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Jul 19 08:13:25 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C94316A402 for ; Thu, 19 Jul 2007 08:13:25 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8259213C481 for ; Thu, 19 Jul 2007 08:13:24 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 86828 invoked from network); 19 Jul 2007 08:09:55 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 19 Jul 2007 08:09:55 -0000 Message-ID: <469F1D32.2040700@freebsd.org> Date: Thu, 19 Jul 2007 10:13:38 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jack Vogel References: <2a41acea0707181152r4c662b00tf1be7b6b4dce74f1@mail.gmail.com> <2a41acea0707181542q23d36733o339448ad86f480cb@mail.gmail.com> In-Reply-To: <2a41acea0707181542q23d36733o339448ad86f480cb@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net , FreeBSD Current Subject: Re: 10G and socket alloc failure X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 08:13:25 -0000 Jack Vogel wrote: > While testing out the ixgbe driver we've observed this failure in the stack > code, here is the info: > > The test engineer is using iperf, typically with 16 threads. If the > driver is using > either legacy or MSI interrupts we will see broken pipes, in dmesg its > due to sonewconn() failing in syncache_socket(). > > Whats interesting is that when I have multiple RX queues configured and > using MSI/X this doesnt happen, at least not very often. > > It does not seem to hurt performance horribly, iperf just spawns another > thread, but I was wondering if there is some underlying tuneable I dont > know about that would stop this from happening?? > > And any theory about why it doesnt happen with multiple queues? Do you see any messages in syslog regarding syncache? -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Jul 19 08:46:56 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE2B416A402 for ; Thu, 19 Jul 2007 08:46:56 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id B558E13C4CA for ; Thu, 19 Jul 2007 08:46:56 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so580374waf for ; Thu, 19 Jul 2007 01:46:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XsQUcigE22aJkQDH9MMtQzHxIR9tAJfcc8d2NdobDTbupga6HKpcxE5xZCfpq+co3u4Aq1ODmMydXpBsnmE4EJOmMDd6diQzlOhMuWC3gxhcnIbtUMyEOfrV426kWyAxqbAqOle6ESFqBe4SqIzwT7wOchfOpOe3EOToRy3mzCg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TXFxWpEKU+/cGczJZFpMxxdfQZLGbtzBOX3rDVQmOb/C4ENXXeiQPCteadUAuIFHILUP3QFofm0Dv/VR0W5pked0vh0F7TfOAYuJroVphCqz6uX6p3CKVFXlI/PPPh6V4qcW/wzMvnxAZF9b97oqpCkFeQr60xnSJsGXUJGt1nk= Received: by 10.114.166.1 with SMTP id o1mr2363352wae.1184834816203; Thu, 19 Jul 2007 01:46:56 -0700 (PDT) Received: by 10.114.103.14 with HTTP; Thu, 19 Jul 2007 01:46:56 -0700 (PDT) Message-ID: <2a41acea0707190146q2fcc5d9cq865e9571cd6104e3@mail.gmail.com> Date: Thu, 19 Jul 2007 01:46:56 -0700 From: "Jack Vogel" To: "Andre Oppermann" In-Reply-To: <469F1D32.2040700@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0707181152r4c662b00tf1be7b6b4dce74f1@mail.gmail.com> <2a41acea0707181542q23d36733o339448ad86f480cb@mail.gmail.com> <469F1D32.2040700@freebsd.org> Cc: freebsd-net , FreeBSD Current Subject: Re: 10G and socket alloc failure X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 08:46:57 -0000 On 7/19/07, Andre Oppermann wrote: > Jack Vogel wrote: > > While testing out the ixgbe driver we've observed this failure in the stack > > code, here is the info: > > > > The test engineer is using iperf, typically with 16 threads. If the > > driver is using > > either legacy or MSI interrupts we will see broken pipes, in dmesg its > > due to sonewconn() failing in syncache_socket(). > > > > Whats interesting is that when I have multiple RX queues configured and > > using MSI/X this doesnt happen, at least not very often. > > > > It does not seem to hurt performance horribly, iperf just spawns another > > thread, but I was wondering if there is some underlying tuneable I dont > > know about that would stop this from happening?? > > > > And any theory about why it doesnt happen with multiple queues? > > Do you see any messages in syslog regarding syncache? Yes, the messages are what are emitted in the code i cited above, I could get the dmesg output if that would provide any more help. I figured the point at which it is failing is pretty specific and someone might know just from that what it was :) Jack From owner-freebsd-net@FreeBSD.ORG Thu Jul 19 08:48:21 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 862DF16A40A for ; Thu, 19 Jul 2007 08:48:21 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 3953613C4DA for ; Thu, 19 Jul 2007 08:48:21 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=UPu7RNH8ANeoqgEKOz5jNjPTL+DweN8OMG1EvxI6Gmdr4yl8C5guLVYlBoNuhFoKG0ECQP13bixG1bFC2QRS4AOa/WD2mg3TD3elmGBNFdq71DUfdXzgBtE7cRmc9Or3YpKAmXIDaTEywq1aFygUGcwKefH747HunmSQ5BoJvR8=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1IBRgH-00008Q-Ay; Thu, 19 Jul 2007 12:48:17 +0400 Date: Thu, 19 Jul 2007 12:48:12 +0400 From: Eygene Ryabinkin To: Julian Elischer Message-ID: <20070719084812.GS4053@void.codelabs.ru> References: <469D4C9D.7090302@ironport.com> <469D4FB6.9040609@elischer.org> <3DBBD4E3-ABEA-451A-8E6A-02E9CBAD6A37@mac.com> <20070718055228.GA4053@void.codelabs.ru> <469E660F.8000109@ironport.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <469E660F.8000109@ironport.com> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.1 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: FreeBSD Net , Julian Elischer Subject: Re: Wierd networking. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 08:48:21 -0000 Julian, good day. Wed, Jul 18, 2007 at 12:12:15PM -0700, Julian Elischer wrote: > >Seems like it is the effect of the SS_NOFDREF check in the > >netinet/tcp_input.c, at least it is present in the rev. 1.281.2.5. > > > >See the post > > http://lists.freebsd.org/pipermail/freebsd-current/2007-July/074837.html > > > > That makes perfect sense.. > thankyou. You're welcome ;))) > I will check this avenue of inquiry. possibly we should do a shutdown() > and let the file descriptor exist for a few seconds. Yes, it is a way to do it. And we may even calculate the amount of time: as I understand, the time estimate is roughly equal to the (TCP window)/(connection bandwidth). The BW is not determined well, but we can try to extract this from the time interval between two successive packets that came from the remote side and the size of these packets. >From the other hand, we may not want to have the per-connection estimate and set it to some small amount of MSLs. Another way to deal with the problem is not to send the FIN's after the one provoked by the closed descriptor. As I understand, the SS_NOFDREF check is a optimization to avoid processing unneeded data in the TCP stack. So we may just silently blackhole the successive packets, at least some of them. -- Eygene From owner-freebsd-net@FreeBSD.ORG Thu Jul 19 16:31:24 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0FEC116A402 for ; Thu, 19 Jul 2007 16:31:24 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outO.internet-mail-service.net (outO.internet-mail-service.net [216.240.47.238]) by mx1.freebsd.org (Postfix) with ESMTP id EBF4113C46B for ; Thu, 19 Jul 2007 16:31:23 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Thu, 19 Jul 2007 09:31:22 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 762ED125AE6; Thu, 19 Jul 2007 09:31:22 -0700 (PDT) Message-ID: <469F91F8.1010406@elischer.org> Date: Thu, 19 Jul 2007 09:31:52 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Eygene Ryabinkin References: <469D4C9D.7090302@ironport.com> <469D4FB6.9040609@elischer.org> <3DBBD4E3-ABEA-451A-8E6A-02E9CBAD6A37@mac.com> <20070718055228.GA4053@void.codelabs.ru> <469E660F.8000109@ironport.com> <20070719084812.GS4053@void.codelabs.ru> In-Reply-To: <20070719084812.GS4053@void.codelabs.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Elischer , FreeBSD Net Subject: Re: Wierd networking. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 16:31:24 -0000 Eygene Ryabinkin wrote: > Julian, good day. > > Wed, Jul 18, 2007 at 12:12:15PM -0700, Julian Elischer wrote: >>> Seems like it is the effect of the SS_NOFDREF check in the >>> netinet/tcp_input.c, at least it is present in the rev. 1.281.2.5. >>> >>> See the post >>> http://lists.freebsd.org/pipermail/freebsd-current/2007-July/074837.html >>> >> That makes perfect sense.. >> thankyou. > > You're welcome ;))) > >> I will check this avenue of inquiry. possibly we should do a shutdown() >> and let the file descriptor exist for a few seconds. > > Yes, it is a way to do it. And we may even calculate the amount > of time: as I understand, the time estimate is roughly equal to the > (TCP window)/(connection bandwidth). The BW is not determined well, > but we can try to extract this from the time interval between two > successive packets that came from the remote side and the size of > these packets. In the code in question I found that there already existed code to do this exactly, except it was only enabled under __LINUX__. it has an event loop, and it continues to keep the file descriptor in the read-interest set until it starts to return EOF, indicating that the other end has also done the close. (or the socket has timed out of FIN_WAIT_1). I have simply enabled it for FreeBSD OR linux ;-) > >>From the other hand, we may not want to have the per-connection > estimate and set it to some small amount of MSLs. > > Another way to deal with the problem is not to send the FIN's after > the one provoked by the closed descriptor. As I understand, the > SS_NOFDREF check is a optimization to avoid processing unneeded > data in the TCP stack. So we may just silently blackhole the > successive packets, at least some of them. From owner-freebsd-net@FreeBSD.ORG Thu Jul 19 16:32:58 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7ACC016A400 for ; Thu, 19 Jul 2007 16:32:58 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outK.internet-mail-service.net (outK.internet-mail-service.net [216.240.47.234]) by mx1.freebsd.org (Postfix) with ESMTP id 4567213C4B9 for ; Thu, 19 Jul 2007 16:32:58 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Thu, 19 Jul 2007 09:32:57 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 3F7C1125AE6; Thu, 19 Jul 2007 09:32:57 -0700 (PDT) Message-ID: <469F9258.1070500@elischer.org> Date: Thu, 19 Jul 2007 09:33:28 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Eygene Ryabinkin References: <469D4C9D.7090302@ironport.com> <469D4FB6.9040609@elischer.org> <3DBBD4E3-ABEA-451A-8E6A-02E9CBAD6A37@mac.com> <20070718055228.GA4053@void.codelabs.ru> <469E660F.8000109@ironport.com> <20070719084812.GS4053@void.codelabs.ru> <469F91F8.1010406@elischer.org> In-Reply-To: <469F91F8.1010406@elischer.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Elischer , FreeBSD Net Subject: Re: Wierd networking. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 16:32:58 -0000 Julian Elischer wrote: > Eygene Ryabinkin wrote: >> Julian, good day. >> >> Wed, Jul 18, 2007 at 12:12:15PM -0700, Julian Elischer wrote: >>>> Seems like it is the effect of the SS_NOFDREF check in the >>>> netinet/tcp_input.c, at least it is present in the rev. 1.281.2.5. >>>> >>>> See the post >>>> >>>> http://lists.freebsd.org/pipermail/freebsd-current/2007-July/074837.html >>>> >>>> >>> That makes perfect sense.. >>> thankyou. >> >> You're welcome ;))) >> >>> I will check this avenue of inquiry. possibly we should do a shutdown() >>> and let the file descriptor exist for a few seconds. >> >> Yes, it is a way to do it. And we may even calculate the amount >> of time: as I understand, the time estimate is roughly equal to the >> (TCP window)/(connection bandwidth). The BW is not determined well, >> but we can try to extract this from the time interval between two >> successive packets that came from the remote side and the size of >> these packets. > > > In the code in question I found that there already existed code to do > this exactly, except it was only enabled under __LINUX__. > it has an event loop, and it continues to keep the file descriptor in > the read-interest set until it starts to return EOF, indicating that the > other end has also done the close. (or the socket has timed out of > FIN_WAIT_1). I have simply enabled it for FreeBSD OR linux ;-) replying to myself.. the comment in the code in question said: /*-----------------------------------------------------------------*/ > /** if the elaborateTCPFin option is set, keeps the socket open > * and drains it until the other side closes it. Solves a problem > * with IE spewing extra client data to a Linux socket, then reporting > * an error in response a TCP reset (rather than FIN) from Linux */ which is EXACTLY the problem I was seeing :-) > > >> >>> From the other hand, we may not want to have the per-connection >> estimate and set it to some small amount of MSLs. >> >> Another way to deal with the problem is not to send the FIN's after >> the one provoked by the closed descriptor. As I understand, the >> SS_NOFDREF check is a optimization to avoid processing unneeded >> data in the TCP stack. So we may just silently blackhole the >> successive packets, at least some of them. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 07:22:37 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBE3716A419 for ; Fri, 20 Jul 2007 07:22:37 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 8E74B13C458 for ; Fri, 20 Jul 2007 07:22:37 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=YgynQ9h+kXB0binwVBfQA9sMJ14ppBT0Gac0mNU6mP8Zxb3omK9oiGMmzV95KYVt7o9TH9+fdwZEHy+o/IiZ+ke6mIyfGftqZflv9jNPO6HBIdfnehmFhTA1N7eq7cvr/km9st+cllXyHB/WX1RUEAXrK3KmGvWZ2ZcwUg9q4s8=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1IBmop-0008m6-J6; Fri, 20 Jul 2007 11:22:31 +0400 Date: Fri, 20 Jul 2007 11:22:27 +0400 From: Eygene Ryabinkin To: Julian Elischer Message-ID: <20070720072227.GD4053@void.codelabs.ru> References: <469D4C9D.7090302@ironport.com> <469D4FB6.9040609@elischer.org> <3DBBD4E3-ABEA-451A-8E6A-02E9CBAD6A37@mac.com> <20070718055228.GA4053@void.codelabs.ru> <469E660F.8000109@ironport.com> <20070719084812.GS4053@void.codelabs.ru> <469F91F8.1010406@elischer.org> <469F9258.1070500@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <469F9258.1070500@elischer.org> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.1 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: Julian Elischer , FreeBSD Net Subject: Re: Wierd networking. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 07:22:37 -0000 Julian, good day. Thu, Jul 19, 2007 at 09:33:28AM -0700, Julian Elischer wrote: > replying to myself.. the comment in the code in question said: > > /*-----------------------------------------------------------------*/ > >/** if the elaborateTCPFin option is set, keeps the socket open > > * and drains it until the other side closes it. Solves a problem > > * with IE spewing extra client data to a Linux socket, then reporting > > * an error in response a TCP reset (rather than FIN) from Linux */ > > which is EXACTLY the problem I was seeing :-) I assume that you're talking about Squid code? Do you think that FreeBSD TCP/IP stack should also do something about this problem? The situation where one side closes the descriptor while other it still trying to push the data is legal: for example, one side invokes close() but some data from other side is in transit, so we will see some unneccessary FIN packets. Or you believe that fixing this is irrelevant? -- Eygene From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 09:56:55 2007 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACA6916A419; Fri, 20 Jul 2007 09:56:55 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 86B2013C46A; Fri, 20 Jul 2007 09:56:55 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l6K9utQi085442; Fri, 20 Jul 2007 09:56:55 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l6K9usE1085438; Fri, 20 Jul 2007 09:56:54 GMT (envelope-from gavin) Date: Fri, 20 Jul 2007 09:56:54 GMT Message-Id: <200707200956.l6K9usE1085438@freefall.freebsd.org> To: rtomimbang@math.upd.edu.ph, gavin@FreeBSD.org, freebsd-net@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/112886: [broadcom]: Wifi card not detected X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 09:56:55 -0000 Synopsis: [broadcom]: Wifi card not detected State-Changed-From-To: open->closed State-Changed-By: gavin State-Changed-When: Fri Jul 20 09:30:28 UTC 2007 State-Changed-Why: Broadcom have not released any documentation for this network card, so it is unlikely there will be a driver for it in FreeBSD any time soon. However, there appear to be several success stories about using this card with the ndis(4) driver, so you should be able to use this card with FreeBSD that way. http://www.freebsd.org/cgi/query-pr.cgi?pr=112886 From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 10:17:40 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 021DA16A417; Fri, 20 Jul 2007 10:17:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id C738C13C458; Fri, 20 Jul 2007 10:17:39 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 85B3248507; Fri, 20 Jul 2007 06:17:39 -0400 (EDT) Date: Fri, 20 Jul 2007 11:17:39 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Max Laier In-Reply-To: <200707172342.39082.max@love2party.net> Message-ID: <20070720111539.U1096@fledge.watson.org> References: <20070717131518.G1177@fledge.watson.org> <200707172342.39082.max@love2party.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, freebsd-pf@freebsd.org, freebsd-arch@freebsd.org Subject: Attention pf/ipfw users with uid/gid/jail rules (Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 10:17:40 -0000 On Tue, 17 Jul 2007, Max Laier wrote: > [ Excess CC-list ... testers needed!!! ] > > On Tuesday 17 July 2007, Robert Watson wrote: >> Dear all: >> >> This is a reminder e-mail that, in the very near future, Giant >> compatibility shims for network protocols will be removed. > > <...> > >> The *only* remaining case I am aware of where removing debug.mpsafenet >> presents an issue is credential-related firewall rules (uid, gid, jail). >> I'm am currently in an active e-mail discussion with the various firewall >> maintainers about how to address this issue; as the implementations of >> these rules violate the global lock order, deadlocks occur if >> debug.mpsafenet isn't set to 1, which causes Giant to act as a guard lock >> preventing parallel lock acquisition in the firewall. Hopefully we will >> have this resolved, in some form, soon. > > What we really need right now, is real understanding of the problem (if > there even is any). So we would like to ask everybody who is able to - to > stress test user/group rules (in pf) or uid/gid/jail rules (in ipfw) with > debug.mpsafenet=1 It is normal that (in an WITNESS enabled kernel) you get a > LOR similar to 14-17 and 32 from [1]. Everything different to those should > be reported. So far I have had 0 (zero) reports of problems since this thread began. Could people using uid/gid/jail rules with ipfw or pf on 7.x *please* try running their firewalls without debug.mpsafenet -- ignore the witness warnings and/or disable witness, and let us know if you experience deadlocks. We're reaching the very end of the merge cycle for 7.0, and I would really like to remove the Giant crutches (now effectively unused) from the network stack so it's not part of the ABI/API, the code is simplified and cleaned up, etc. We'll need to figure out the best way to suppress these witness warnings without suppressing too many other things still. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 12:55:10 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4508116A421 for ; Fri, 20 Jul 2007 12:55:10 +0000 (UTC) (envelope-from karels@redrock.karels.net) Received: from redrock.karels.net (redrock.karels.net [206.196.45.2]) by mx1.freebsd.org (Postfix) with ESMTP id 04DC513C4DB for ; Fri, 20 Jul 2007 12:55:09 +0000 (UTC) (envelope-from karels@redrock.karels.net) Received: from redrock.karels.net (localhost.karels.net [127.0.0.1]) by redrock.karels.net (8.13.8/8.13.6) with ESMTP id l6KCpx7G033770; Fri, 20 Jul 2007 07:52:00 -0500 (CDT) (envelope-from karels@redrock.karels.net) Message-Id: <200707201252.l6KCpx7G033770@redrock.karels.net> To: Julian Elischer From: Mike Karels In-reply-to: Your message of Wed, 18 Jul 2007 20:46:47 -0700. <469EDEA7.9000606@elischer.org> Date: Fri, 20 Jul 2007 07:51:59 -0500 Sender: karels@karels.net Cc: Tom Judge , freebsd-net@freebsd.org Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: karels@karels.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 12:55:10 -0000 > Mike Karels wrote: > >> There are also things to consider such as if a GigE card is connected to > >> a GigE device (switch/card etc) and the card supports jumbo frames > >> should the MRU be set to the max jumbo receive size for the card? This > >> could cause confusion when people plug jumbo capable devices in with > >> hardware limitations making the MRU lower than other devices on the network. > > > > Although we don't have an MRU explicitly, we don't enable reception > > of jumbo frames without administrator action. There is an IFCAP_JUMBO_MTU > > flag defined, but not previously used as far as I know. We added the > > ability to set that flag with ifconfig, which enables reception of > > jumbo frames without changing the MTU. Then, in ether_input, we accept > > any packet that a NIC sees fit to receive. > for what values of "we"? Sorry, that's Secure Computing. I was elaborating on a change I had mentioned earlier. Mike From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 15:22:41 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FD9F16A421 for ; Fri, 20 Jul 2007 15:22:41 +0000 (UTC) (envelope-from anderson@more.net) Received: from betaray.spg.more.net (betaray.spg.more.net [207.160.133.137]) by mx1.freebsd.org (Postfix) with ESMTP id 42CDB13C457 for ; Fri, 20 Jul 2007 15:22:41 +0000 (UTC) (envelope-from anderson@more.net) Received: by betaray.spg.more.net (Postfix, from userid 1000) id 4E2621A090E; Fri, 20 Jul 2007 09:59:32 -0500 (CDT) Date: Fri, 20 Jul 2007 09:59:32 -0500 From: "Eric L. Anderson" To: freebsd-net@freebsd.org Message-ID: <20070720145932.GP6053@more.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 Subject: Max NFS mounts for a FreeBSD client? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 15:22:41 -0000 What is the limit of NFS mounts a FreeBSD server can make and how do you modify this limit? The only reference I could find to this question on the FreeBSD lists is http://lists.freebsd.org/pipermail/freebsd-questions/2004-July/051947.html I have ran a similar test and the same thing happens after 420 NFS mounts. This is on both FreeBSD 6.0 and 6.2. We have recently run into a problem where we are bumping up against some kind of limit to the number of NFS mounts on our FreeBSD servers. Thanks -- Eric L. Anderson anderson@more.net From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 15:55:01 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F53D16A418 for ; Fri, 20 Jul 2007 15:55:01 +0000 (UTC) (envelope-from lavalamp@spiritual-machines.org) Received: from mail.digitalfreaks.org (arbitor.digitalfreaks.org [216.151.95.158]) by mx1.freebsd.org (Postfix) with ESMTP id 1EA5013C461 for ; Fri, 20 Jul 2007 15:55:01 +0000 (UTC) (envelope-from lavalamp@spiritual-machines.org) Received: by mail.digitalfreaks.org (Postfix, from userid 1022) id 53D07170E9; Fri, 20 Jul 2007 11:37:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.digitalfreaks.org (Postfix) with ESMTP id 521F4170B8 for ; Fri, 20 Jul 2007 11:37:44 -0400 (EDT) Date: Fri, 20 Jul 2007 11:37:44 -0400 (EDT) From: "Brian A. Seklecki" X-X-Sender: lavalamp@arbitor.digitalfreaks.org To: freebsd-net@freebsd.org Message-ID: <20070720113322.Q62485@arbitor.digitalfreaks.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: checking SO_ACCEPTFILTER with netstat(1)/sockstat(1) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 15:55:01 -0000 Neither appear to support extracting the setsockopt(2) list. lsof(8) to the rescue: $ sudo lsof -T f | grep -i ACCEPTF | more httpd 38396 root 3u IPv6 0xc2824378 0t0 TCP *:http (SO=ACCEPTCONN,ACCEPTFILTER,KEEPALIVE,PQLEN=0,QLEN=0,QLIM= ^^^^^^^^ 128,RCVBUF=262144,REUSEADDR,SNDBUF=262144 TF=MSS=1024,NODELAY,REQ_SCALE,REQ_TSTMP) A little bit more definitive than "Oh hey apache stopped complaining." Any other way? l8* -lava (Brian A. Seklecki - Pittsburgh, PA, USA) http://www.spiritual-machines.org/ "Guilty? Yeah. But he knows it. I mean, you're guilty. You just don't know it. So who's really in jail?" ~Maynard James Keenan From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 16:51:49 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18FDF16A419 for ; Fri, 20 Jul 2007 16:51:49 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.freebsd.org (Postfix) with ESMTP id 8132C13C468 for ; Fri, 20 Jul 2007 16:51:48 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost.int.ru [127.0.0.1] (may be forged)) by mp2.macomnet.net (8.13.7/8.13.8) with ESMTP id l6KGJ6Ep053445; Fri, 20 Jul 2007 20:19:07 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Fri, 20 Jul 2007 20:19:06 +0400 (MSD) From: Maxim Konovalov To: "Brian A. Seklecki" In-Reply-To: <20070720113322.Q62485@arbitor.digitalfreaks.org> Message-ID: <20070720201507.Y20123@mp2.macomnet.net> References: <20070720113322.Q62485@arbitor.digitalfreaks.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: checking SO_ACCEPTFILTER with netstat(1)/sockstat(1) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 16:51:49 -0000 On Fri, 20 Jul 2007, 11:37-0400, Brian A. Seklecki wrote: > > Neither appear to support extracting the setsockopt(2) list. lsof(8) to the > rescue: > > $ sudo lsof -T f | grep -i ACCEPTF | more > > httpd 38396 root 3u IPv6 0xc2824378 0t0 TCP *:http > (SO=ACCEPTCONN,ACCEPTFILTER,KEEPALIVE,PQLEN=0,QLEN=0,QLIM= > ^^^^^^^^ > 128,RCVBUF=262144,REUSEADDR,SNDBUF=262144 > TF=MSS=1024,NODELAY,REQ_SCALE,REQ_TSTMP) > > A little bit more definitive than "Oh hey apache stopped complaining." > > > Any other way? > I think lsof(8) just parses net.inet.tcp.pcblist OID. You could look at struct xtcpcb definition and extract xtcpcb.xt_socket.so_options from the above sysctl. HTH. -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 17:04:35 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2FA116A421 for ; Fri, 20 Jul 2007 17:04:35 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4A05713C4D9 for ; Fri, 20 Jul 2007 17:04:35 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 31E8C46B95; Fri, 20 Jul 2007 13:04:34 -0400 (EDT) Date: Fri, 20 Jul 2007 18:04:34 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Eygene Ryabinkin In-Reply-To: <20070719084812.GS4053@void.codelabs.ru> Message-ID: <20070720175713.S39675@fledge.watson.org> References: <469D4C9D.7090302@ironport.com> <469D4FB6.9040609@elischer.org> <3DBBD4E3-ABEA-451A-8E6A-02E9CBAD6A37@mac.com> <20070718055228.GA4053@void.codelabs.ru> <469E660F.8000109@ironport.com> <20070719084812.GS4053@void.codelabs.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Julian Elischer , FreeBSD Net , Julian Elischer Subject: Re: Wierd networking. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 17:04:36 -0000 On Thu, 19 Jul 2007, Eygene Ryabinkin wrote: > Another way to deal with the problem is not to send the FIN's after the one > provoked by the closed descriptor. As I understand, the SS_NOFDREF check is > a optimization to avoid processing unneeded data in the TCP stack. So we > may just silently blackhole the successive packets, at least some of them. While it could be it also does that, SS_NOFDREF is actually part of the socket state cycle, and used in part to determine when it is appropriate to free a socket. As you observe, the key here is that there are actually three separate and somewhat independent state cycles going on here: the file descriptor state cycle, the socket state cycle, and the TCP state cycle. This is further complicated by the fact that we actually have a three-part state model for TCP, allowing reduced state to be maintained during the three-way handshake on the server, and during the TIMEWAIT state. The trick is to properly manage the API/protocol interactions and the data structures. In FreeBSD 6.x and earlier, we have a moderately large number of bugs relating to mishandling of freed TCP state, and in FreeBSD 7 in order to reduce complexity and locking requirements, we moved to a model in which it is an invariant of the socket<->pcb relationship that a valid PCB is present for all "live" sockets. As such, the so->so_pcb pointer is always valid, and any valid socket will always have valid TCP state. However, the inverse is only sometimes true: we may free socket state when in the final stages of the TCP connection in order to avoid keeping around the memory overhead of the socket and socket buffers during, for example, TIMEWAIT. If you look at sofree() in 7.x, you'll see the logic we use to determine whether it's time to free the socket itself or not: if ((so->so_state & SS_NOFDREF) == 0 || so->so_count != 0 || (so->so_state & SS_PROTOREF) || (so->so_qstate & SQ_COMP)) { SOCK_UNLOCK(so); ACCEPT_UNLOCK(); return; } Notice that we have both an explicit reference count and several flags that are effectively also references. SS_NOFDREF is set when a file descriptor, if there has ever been one for the socket, has its reference removed. SS_PROTOREF means that the protocol has asserted a reference on the socket -- for example, if the socket is closed but there is still pending data to be sent out, so the socket buffers are required. SQ_COMP is set if the socket is in a listen queue. Over the last two years, I've been gradually attempting to move to explicit reference models, strong and well-document invariants about the stability of the pointers that span layers (i.e., inp_ppcb, inp_socket, so_pcb, etc), as well as gradually simplifying the model. It wouldn't surprise me if issues remain. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 17:07:39 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4456D16A474 for ; Fri, 20 Jul 2007 17:07:39 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0A2BE13C468 for ; Fri, 20 Jul 2007 17:07:39 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id DF83446B95; Fri, 20 Jul 2007 13:07:37 -0400 (EDT) Date: Fri, 20 Jul 2007 18:07:37 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Eric L. Anderson" In-Reply-To: <20070720145932.GP6053@more.net> Message-ID: <20070720180546.X39675@fledge.watson.org> References: <20070720145932.GP6053@more.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Max NFS mounts for a FreeBSD client? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 17:07:39 -0000 On Fri, 20 Jul 2007, Eric L. Anderson wrote: > What is the limit of NFS mounts a FreeBSD server can make and how do you > modify this limit? > > The only reference I could find to this question on the FreeBSD lists is > http://lists.freebsd.org/pipermail/freebsd-questions/2004-July/051947.html > > I have ran a similar test and the same thing happens after 420 NFS mounts. > This is on both FreeBSD 6.0 and 6.2. > > We have recently run into a problem where we are bumping up against some > kind of limit to the number of NFS mounts on our FreeBSD servers. Sounds a bit like something is running out of reserved ports to use -- the credentials error may mean that a port number >1023 was used for an NFS connection. Given that reserved ports start around 600, 420 is about the right number of sockets to reach 1024. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 17:20:21 2007 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE58F16A41A for ; Fri, 20 Jul 2007 17:20:21 +0000 (UTC) (envelope-from SRS0=a3fa025e4cd4e551cf489a0571430d1df480ce2b=402=es.net=dart@es.net) Received: from postal1.es.net (postal1.es.net [IPv6:2001:400:14:3::6]) by mx1.freebsd.org (Postfix) with ESMTP id 8EA3D13C4B3 for ; Fri, 20 Jul 2007 17:20:21 +0000 (UTC) (envelope-from SRS0=a3fa025e4cd4e551cf489a0571430d1df480ce2b=402=es.net=dart@es.net) Received: from [192.168.13.32] (c-24-4-182-157.hsd1.ca.comcast.net [24.4.182.157]) by postal1.es.net (Postal Node 1) with ASMTP (SSL) id ZYO79220 for ; Fri, 20 Jul 2007 10:20:20 -0700 Date: Fri, 20 Jul 2007 10:19:58 -0700 From: Eli Dart User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: freebsd-net@FreeBSD.org References: <200707150237.l6F2bAgZ011098@redrock.karels.net> <469E0FFF.8070802@seclark.us> In-Reply-To: <469E0FFF.8070802@seclark.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-Id: <20070720172021.8EA3D13C4B3@mx1.freebsd.org> Cc: Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 17:20:22 -0000 Stephen Clark wrote: >> > So was any decision reached on this issue - will FreeBSD changed to > accept a packet on an > interface that is larger than the mtu on that interface? If possible, I'd like to see the ability to enforce interface MTU for received packets preserved in a sysctl if it is removed for the default config... In other words, something like: net.link.mtu_limits_received_pktsize = 0|1 Then, default it to 0 to preserve 4.x behavior. Thanks, --eli -- Eli Dart Office: (510) 486-5629 ESnet Network Engineering Group Fax: (510) 486-6712 Lawrence Berkeley National Laboratory PGP Key fingerprint = C970 F8D3 CFDD 8FFF 5486 343A 2D31 4478 5F82 B2B3 From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 17:48:05 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D985716A417 for ; Fri, 20 Jul 2007 17:48:05 +0000 (UTC) (envelope-from fox@verio.net) Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1.email.verio.net [129.250.36.41]) by mx1.freebsd.org (Postfix) with ESMTP id AAC1C13C467 for ; Fri, 20 Jul 2007 17:48:05 +0000 (UTC) (envelope-from fox@verio.net) Received: from [129.250.36.63] (helo=dfw-mmp3.email.verio.net) by dfw-smtpout1.email.verio.net with esmtp id 1IBwaD-0007f8-26 for freebsd-net@freebsd.org; Fri, 20 Jul 2007 17:48:05 +0000 Received: from [129.250.40.241] (helo=limbo.int.dllstx01.us.it.verio.net) by dfw-mmp3.email.verio.net with esmtp id 1IBwaC-0001fo-Uf for freebsd-net@freebsd.org; Fri, 20 Jul 2007 17:48:04 +0000 Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id 65FC58E296; Fri, 20 Jul 2007 12:48:04 -0500 (CDT) Date: Fri, 20 Jul 2007 12:48:04 -0500 From: David DeSimone To: freebsd-net@freebsd.org Message-ID: <20070720174803.GC12522@verio.net> Mail-Followup-To: freebsd-net@freebsd.org References: <200707150237.l6F2bAgZ011098@redrock.karels.net> <469E0FFF.8070802@seclark.us> <20070720172021.8EA3D13C4B3@mx1.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <20070720172021.8EA3D13C4B3@mx1.freebsd.org> Precedence: bulk User-Agent: Mutt/1.5.9i Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 17:48:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eli Dart wrote: > > If possible, I'd like to see the ability to enforce interface MTU for > received packets preserved in a sysctl if it is removed for the > default config... I'm curious, why do you want this feature? - -- David DeSimone == Network Admin == fox@verio.net "It took me fifteen years to discover that I had no talent for writing, but I couldn't give it up because by that time I was too famous. -- Robert Benchley -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFGoPVTFSrKRjX5eCoRAojNAJ9CR7RLgerc54o3ourw99HjzA7DmgCfW+l9 wHLV1uPPfBlYb7dAVnGnyL0= =RPou -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 18:23:34 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D00E416A419 for ; Fri, 20 Jul 2007 18:23:34 +0000 (UTC) (envelope-from prvs=julian=714f3ef81@ironport.com) Received: from c60-outbound.ironport.com (c60-outbound.ironport.com [63.251.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id AF95E13C48E for ; Fri, 20 Jul 2007 18:23:34 +0000 (UTC) (envelope-from prvs=julian=714f3ef81@ironport.com) Received: from jelischer-laptop.sfo.ironport.com (HELO julian-mac.elischer.org) ([10.251.22.38]) by c60-outbound.ironport.com with ESMTP; 20 Jul 2007 10:54:45 -0700 Message-ID: <46A0F706.6020701@ironport.com> Date: Fri, 20 Jul 2007 10:55:18 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Eygene Ryabinkin References: <469D4C9D.7090302@ironport.com> <469D4FB6.9040609@elischer.org> <3DBBD4E3-ABEA-451A-8E6A-02E9CBAD6A37@mac.com> <20070718055228.GA4053@void.codelabs.ru> <469E660F.8000109@ironport.com> <20070719084812.GS4053@void.codelabs.ru> <469F91F8.1010406@elischer.org> <469F9258.1070500@elischer.org> <20070720072227.GD4053@void.codelabs.ru> In-Reply-To: <20070720072227.GD4053@void.codelabs.ru> Content-Type: multipart/mixed; boundary="------------050007080702000501050000" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Net , Julian Elischer Subject: Re: Wierd networking. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 18:23:34 -0000 This is a multi-part message in MIME format. --------------050007080702000501050000 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Eygene Ryabinkin wrote: > Julian, good day. > > Thu, Jul 19, 2007 at 09:33:28AM -0700, Julian Elischer wrote: > >> replying to myself.. the comment in the code in question said: >> >> /*-----------------------------------------------------------------*/ >> >>> /** if the elaborateTCPFin option is set, keeps the socket open >>> * and drains it until the other side closes it. Solves a problem >>> * with IE spewing extra client data to a Linux socket, then reporting >>> * an error in response a TCP reset (rather than FIN) from Linux */ >>> >> which is EXACTLY the problem I was seeing :-) >> > > I assume that you're talking about Squid code? > no this is a proprietary cache program.. > Do you think that FreeBSD TCP/IP stack should also do something > about this problem? The situation where one side closes the > descriptor while other it still trying to push the data is legal: > for example, one side invokes close() but some data from other side > is in transit, so we will see some unneccessary FIN packets. Or > you believe that fixing this is irrelevant? > I think that the possible courses of action are: 1/ Ignore further incoming data, but ACK it. (this is basically what the userland code does in this case) 2/ Stop ACKing the data, and let the other end time out. 3/ Send a RST --------------050007080702000501050000-- From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 18:34:53 2007 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23A3816A476 for ; Fri, 20 Jul 2007 18:34:53 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outO.internet-mail-service.net (outO.internet-mail-service.net [216.240.47.238]) by mx1.freebsd.org (Postfix) with ESMTP id 5735C13C4A8 for ; Fri, 20 Jul 2007 18:34:50 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 20 Jul 2007 11:34:49 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 7858E125A24; Fri, 20 Jul 2007 11:34:49 -0700 (PDT) Message-ID: <46A10063.9010902@elischer.org> Date: Fri, 20 Jul 2007 11:35:15 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Eli Dart References: <200707150237.l6F2bAgZ011098@redrock.karels.net> <469E0FFF.8070802@seclark.us> <20070720172021.8EA3D13C4B3@mx1.freebsd.org> In-Reply-To: <20070720172021.8EA3D13C4B3@mx1.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 18:34:53 -0000 Eli Dart wrote: > > > Stephen Clark wrote: > >>> >> So was any decision reached on this issue - will FreeBSD changed to >> accept a packet on an >> interface that is larger than the mtu on that interface? > > If possible, I'd like to see the ability to enforce interface MTU for > received packets preserved in a sysctl if it is removed for the default > config... In other words, something like: > > net.link.mtu_limits_received_pktsize = 0|1 > > Then, default it to 0 to preserve 4.x behavior. what would this achieve? Answering himself.. it MAY allow a driver to optimise a bit by not needing to cope with the posibility of receiving jubo packets? I can not think of any other reason.. (except to break networks that are apparently working fine). > > Thanks, > > --eli > From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 18:36:18 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F34216A421 for ; Fri, 20 Jul 2007 18:36:18 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outU.internet-mail-service.net (outU.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id 286FD13C474 for ; Fri, 20 Jul 2007 18:36:18 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 20 Jul 2007 11:36:17 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 429B2125A23; Fri, 20 Jul 2007 11:36:17 -0700 (PDT) Message-ID: <46A100C2.1030606@elischer.org> Date: Fri, 20 Jul 2007 11:36:50 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Robert Watson References: <20070717131518.G1177@fledge.watson.org> <200707172342.39082.max@love2party.net> <20070720111539.U1096@fledge.watson.org> In-Reply-To: <20070720111539.U1096@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Max Laier , freebsd-arch@freebsd.org, freebsd-current@freebsd.org, freebsd-pf@freebsd.org, freebsd-net@freebsd.org Subject: Re: Attention pf/ipfw users with uid/gid/jail rules (Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 18:36:18 -0000 Robert Watson wrote: > > On Tue, 17 Jul 2007, Max Laier wrote: > > So far I have had 0 (zero) reports of problems since this thread began. > Could people using uid/gid/jail rules with ipfw or pf on 7.x *please* > try running their firewalls without debug.mpsafenet -- ignore the > witness warnings and/or disable witness, and let us know if you > experience deadlocks. We're reaching the very end of the merge cycle > for 7.0, and I would really like to remove the Giant crutches (now > effectively unused) from the network stack so it's not part of the > ABI/API, the code is simplified and cleaned up, etc. > does "problem" include a LOR message, or only a deadlock? I've seen plenty of the first, but not the second. From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 19:09:44 2007 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3F3816A41B for ; Fri, 20 Jul 2007 19:09:44 +0000 (UTC) (envelope-from SRS0=a3fa025e4cd4e551cf489a0571430d1df480ce2b=402=es.net=dart@es.net) Received: from postal1.es.net (postal1.es.net [IPv6:2001:400:14:3::6]) by mx1.freebsd.org (Postfix) with ESMTP id 71AC713C442 for ; Fri, 20 Jul 2007 19:09:44 +0000 (UTC) (envelope-from SRS0=a3fa025e4cd4e551cf489a0571430d1df480ce2b=402=es.net=dart@es.net) Received: from [192.168.13.32] (c-24-4-182-157.hsd1.ca.comcast.net [24.4.182.157]) by postal1.es.net (Postal Node 1) with ASMTP (SSL) id ZAD61743; Fri, 20 Jul 2007 12:09:43 -0700 Message-ID: <46A10860.50804@es.net> Date: Fri, 20 Jul 2007 12:09:20 -0700 From: Eli Dart User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Julian Elischer References: <200707150237.l6F2bAgZ011098@redrock.karels.net> <469E0FFF.8070802@seclark.us> <20070720172021.8EA3D13C4B3@mx1.freebsd.org> <46A10063.9010902@elischer.org> In-Reply-To: <46A10063.9010902@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 19:09:45 -0000 see below... Julian Elischer wrote: > Eli Dart wrote: >> >> >> Stephen Clark wrote: >> >>>> >>> So was any decision reached on this issue - will FreeBSD changed >>> to accept a packet on an interface that is larger than the mtu on >>> that interface? >> >> If possible, I'd like to see the ability to enforce interface MTU >> for received packets preserved in a sysctl if it is removed for the >> default config... In other words, something like: >> >> net.link.mtu_limits_received_pktsize = 0|1 >> >> Then, default it to 0 to preserve 4.x behavior. > > what would this achieve? > > Answering himself.. it MAY allow a driver to optimise a bit by not > needing to cope with the posibility of receiving jubo packets? I can > not think of any other reason.. (except to break networks that are > apparently working fine). The networks that are apparently working fine are most likely misconfigured, IMHO. Others have made a case for permitting an interface to accept as large a packet as it can, regardless of configured MTU. That's fine for theory. My operational experience leads me to a different place. If an interface receives a packet that is larger than its configured MTU, I would prefer that the packet be dropped as a giant and a giants counter incremented, regardless of whether the hardware can theoretically receive the packet. In modern networks, an MTU mismatch within a broadcast domain indicates a broken network, IMHO. If the devices in the network are configured to enforce MTU for both tx and rx, more problems get spotted during turnup, rather than surfacing later on as difficult-to-diagnose problems that users only call about after they are truly frustrated. And, if you have a giants counter (or input error counter) you can look at, it makes it straightforward to spot the problem. (one could also stretch a bit and say that enforcing MTU on rx might provide less surprise to code that consumes packets and has knowledge of the MTU setting of an interface.....unfortunately I don't know enough about the details of the network stack to know if this is a real concern) Many thanks, --eli -- Eli Dart Office: (510) 486-5629 ESnet Network Engineering Group Fax: (510) 486-6712 Lawrence Berkeley National Laboratory PGP Key fingerprint = C970 F8D3 CFDD 8FFF 5486 343A 2D31 4478 5F82 B2B3 From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 19:35:05 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34C9916A417; Fri, 20 Jul 2007 19:35:05 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: from regurgitate.ugcs.caltech.edu (regurgitate.ugcs.caltech.edu [131.215.176.97]) by mx1.freebsd.org (Postfix) with ESMTP id 0B21413C457; Fri, 20 Jul 2007 19:35:05 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: by regurgitate.ugcs.caltech.edu (Postfix, from userid 3640) id 04D80E8AC; Fri, 20 Jul 2007 12:12:01 -0700 (PDT) Date: Fri, 20 Jul 2007 12:12:01 -0700 From: Paul Allen To: Julian Elischer Message-ID: <20070720191201.GE5504@regurgitate.ugcs.caltech.edu> References: <20070717131518.G1177@fledge.watson.org> <200707172342.39082.max@love2party.net> <20070720111539.U1096@fledge.watson.org> <46A100C2.1030606@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46A100C2.1030606@elischer.org> Sender: jd@ugcs.caltech.edu Cc: freebsd-net@freebsd.org, freebsd-arch@freebsd.org, freebsd-current@freebsd.org, Robert Watson , freebsd-pf@freebsd.org, Max Laier Subject: Re: Attention pf/ipfw users with uid/gid/jail rules (Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 19:35:05 -0000 >From Julian Elischer , Fri, Jul 20, 2007 at 11:36:50AM -0700: > Robert Watson wrote: > > > >On Tue, 17 Jul 2007, Max Laier wrote: > > > >So far I have had 0 (zero) reports of problems since this thread began. > >Could people using uid/gid/jail rules with ipfw or pf on 7.x *please* > >try running their firewalls without debug.mpsafenet -- ignore the > >witness warnings and/or disable witness, and let us know if you > >experience deadlocks. We're reaching the very end of the merge cycle > >for 7.0, and I would really like to remove the Giant crutches (now > >effectively unused) from the network stack so it's not part of the > >ABI/API, the code is simplified and cleaned up, etc. Wasn't there a a clear solution to the uid/gid problem involving flip-pages: eliminate the pf lock by forcing reconfigurations to build a parallel data-structure and then perform an atomic operation to exchange the pointers. AFAIK, Max's patch was just an ugly hack and it isn't really suitable for performance reasons. What's the state of MAC for the networking stack? Are we able to restrict particular uid's to listening only on particular ports? From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 20:29:24 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94B0C16A417; Fri, 20 Jul 2007 20:29:24 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id E003013C45A; Fri, 20 Jul 2007 20:29:23 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 9528346B95; Fri, 20 Jul 2007 16:29:22 -0400 (EDT) Date: Fri, 20 Jul 2007 21:29:22 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Paul Allen In-Reply-To: <20070720191201.GE5504@regurgitate.ugcs.caltech.edu> Message-ID: <20070720212206.J83919@fledge.watson.org> References: <20070717131518.G1177@fledge.watson.org> <200707172342.39082.max@love2party.net> <20070720111539.U1096@fledge.watson.org> <46A100C2.1030606@elischer.org> <20070720191201.GE5504@regurgitate.ugcs.caltech.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-arch@freebsd.org, freebsd-current@freebsd.org, Julian Elischer , freebsd-pf@freebsd.org, Max Laier Subject: Re: Attention pf/ipfw users with uid/gid/jail rules (Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 20:29:24 -0000 On Fri, 20 Jul 2007, Paul Allen wrote: > From Julian Elischer , Fri, Jul 20, 2007 at 11:36:50AM -0700: >> Robert Watson wrote: >>> On Tue, 17 Jul 2007, Max Laier wrote: >>> >>> So far I have had 0 (zero) reports of problems since this thread began. >>> Could people using uid/gid/jail rules with ipfw or pf on 7.x *please* try >>> running their firewalls without debug.mpsafenet -- ignore the witness >>> warnings and/or disable witness, and let us know if you experience >>> deadlocks. We're reaching the very end of the merge cycle for 7.0, and I >>> would really like to remove the Giant crutches (now effectively unused) >>> from the network stack so it's not part of the ABI/API, the code is >>> simplified and cleaned up, etc. > > Wasn't there a a clear solution to the uid/gid problem involving flip-pages: > eliminate the pf lock by forcing reconfigurations to build a parallel > data-structure and then perform an atomic operation to exchange the > pointers. I think there are a few potential solutions and areas for work here, the trick is figuring out the best approach to get 7.0 out the door. I think any long term structural changes to the firewalls should be avoided at this point, and targeted at 7.1 or 8.0. FYI, my feeling is that the current approach taken, using a pcb lookup in the firewall, is not really an appropriate solution to the problem. Among other things, there are (small) race conditions such that the lookup could return one pcb in the input path and use that for the check, but another pcb during TCP-layer delivery. The lock order reversal warning is a symptom of reaching across layers in fairly ugly (and atomicity-unsafe) ways. One idea that I'd been pondering was having the inpcb code in the TCP/UDP/SCTP/etc layers invoke event handlers as bindings/connections are made, making credentials and other information available to firewall packages, which could then cache information under their own locks. > AFAIK, Max's patch was just an ugly hack and it isn't really suitable for > performance reasons. > > What's the state of MAC for the networking stack? Are we able to restrict > particular uid's to listening only on particular ports? See mac_portacl(4), which is a functional but not particularly elegant implementation of this idea. In Mac OS X Leopard, many of the traditional "firewall" sorts of checks are now performed at the socket layer using this sort of approach -- this provides greater application context, allows control of things like binding/listening, not just packet transmission and receipt, and provides access to the data as received at the application layer rather than at the datagram layer, avoiding the need for normalization. The MAC Framework will not be enabled by default in 7.0, but one of my goals for 8.0 is to ship the framework enabled in GENERIC by default. This will require a significant amount of performance optimization to do. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 20:33:42 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A51516A419; Fri, 20 Jul 2007 20:33:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id F359A13C467; Fri, 20 Jul 2007 20:33:41 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 902AE48748; Fri, 20 Jul 2007 16:33:40 -0400 (EDT) Date: Fri, 20 Jul 2007 21:33:40 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <46A100C2.1030606@elischer.org> Message-ID: <20070720213241.N83919@fledge.watson.org> References: <20070717131518.G1177@fledge.watson.org> <200707172342.39082.max@love2party.net> <20070720111539.U1096@fledge.watson.org> <46A100C2.1030606@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Max Laier , freebsd-arch@freebsd.org, freebsd-current@freebsd.org, freebsd-pf@freebsd.org, freebsd-net@freebsd.org Subject: Re: Attention pf/ipfw users with uid/gid/jail rules (Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 20:33:42 -0000 On Fri, 20 Jul 2007, Julian Elischer wrote: > Robert Watson wrote: >> >> On Tue, 17 Jul 2007, Max Laier wrote: >> >> So far I have had 0 (zero) reports of problems since this thread began. >> Could people using uid/gid/jail rules with ipfw or pf on 7.x *please* try >> running their firewalls without debug.mpsafenet -- ignore the witness >> warnings and/or disable witness, and let us know if you experience >> deadlocks. We're reaching the very end of the merge cycle for 7.0, and I >> would really like to remove the Giant crutches (now effectively unused) >> from the network stack so it's not part of the ABI/API, the code is >> simplified and cleaned up, etc. > > does "problem" include a LOR message, or only a deadlock? I've seen plenty > of the first, but not the second. Deadlocks. The LOR is expected, but actually a false positive with respect to deadlock potential, we now believe. To be specific: there is a cycle, but since the cycling conditions always involve read acquisition, they shouldn't lead to a wait cycle. So what we're looking for here is evidence of something more than the WITNESS warning. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 22:34:33 2007 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0E0B16A417 for ; Fri, 20 Jul 2007 22:34:33 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outP.internet-mail-service.net (outP.internet-mail-service.net [216.240.47.239]) by mx1.freebsd.org (Postfix) with ESMTP id A498413C442 for ; Fri, 20 Jul 2007 22:34:33 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 20 Jul 2007 15:34:32 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 3C25B125AE1; Fri, 20 Jul 2007 15:34:32 -0700 (PDT) Message-ID: <46A13891.5040201@elischer.org> Date: Fri, 20 Jul 2007 15:34:57 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Eli Dart References: <200707150237.l6F2bAgZ011098@redrock.karels.net> <469E0FFF.8070802@seclark.us> <20070720172021.8EA3D13C4B3@mx1.freebsd.org> <46A10063.9010902@elischer.org> <46A10860.50804@es.net> In-Reply-To: <46A10860.50804@es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 22:34:33 -0000 Eli Dart wrote: > see below... > > Julian Elischer wrote: >> Eli Dart wrote: >>> >>> >>> Stephen Clark wrote: >>> >>>>> >>>> So was any decision reached on this issue - will FreeBSD changed >>>> to accept a packet on an interface that is larger than the mtu on >>>> that interface? >>> >>> If possible, I'd like to see the ability to enforce interface MTU >>> for received packets preserved in a sysctl if it is removed for the >>> default config... In other words, something like: >>> >>> net.link.mtu_limits_received_pktsize = 0|1 >>> >>> Then, default it to 0 to preserve 4.x behavior. >> >> what would this achieve? >> >> Answering himself.. it MAY allow a driver to optimise a bit by not >> needing to cope with the posibility of receiving jubo packets? I can >> not think of any other reason.. (except to break networks that are >> apparently working fine). > > The networks that are apparently working fine are most likely > misconfigured, IMHO. > > Others have made a case for permitting an interface to accept as large a > packet as it can, regardless of configured MTU. That's fine for theory. > > My operational experience leads me to a different place. If an > interface receives a packet that is larger than its configured MTU, I > would prefer that the packet be dropped as a giant and a giants counter > incremented, regardless of whether the hardware can theoretically > receive the packet. In modern networks, an MTU mismatch within a > broadcast domain indicates a broken network, IMHO. If the devices in > the network are configured to enforce MTU for both tx and rx, more > problems get spotted during turnup, rather than surfacing later on as > difficult-to-diagnose problems that users only call about after they are > truly frustrated. And, if you have a giants counter (or input error > counter) you can look at, it makes it straightforward to spot the problem. > > (one could also stretch a bit and say that enforcing MTU on rx might > provide less surprise to code that consumes packets and has knowledge of > the MTU setting of an interface.....unfortunately I don't know enough > about the details of the network stack to know if this is a real concern) then we should have an MRU value. mtu is mTu note that if the following code is what is doing it, it is only enabled in DIAGNOSTIC mode anyhow. #ifdef DIAGNOSTIC if (m->m_pkthdr.len > ETHER_MAX_FRAME(ifp, etype, m->m_flags & M_HASFCS) && (ifp->if_capenable & IFCAP_LRO) == 0) { if_printf(ifp, "discard oversize frame " "(ether type %x flags %x len %u > max %lu)\n", etype, m->m_flags, m->m_pkthdr.len, ETHER_MAX_FRAME(ifp, etype, m->m_flags & M_HASFCS)); ifp->if_ierrors++; m_freem(m); return; } personally I'd just remove it. > > Many thanks, > > --eli > > From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 22:43:04 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31F1616A41F for ; Fri, 20 Jul 2007 22:43:04 +0000 (UTC) (envelope-from karels@redrock.karels.net) Received: from redrock.karels.net (redrock.karels.net [206.196.45.2]) by mx1.freebsd.org (Postfix) with ESMTP id DF62D13C468 for ; Fri, 20 Jul 2007 22:43:03 +0000 (UTC) (envelope-from karels@redrock.karels.net) Received: from redrock.karels.net (localhost.karels.net [127.0.0.1]) by redrock.karels.net (8.13.8/8.13.6) with ESMTP id l6KMdSq4035780; Fri, 20 Jul 2007 17:39:29 -0500 (CDT) (envelope-from karels@redrock.karels.net) Message-Id: <200707202239.l6KMdSq4035780@redrock.karels.net> To: Julian Elischer From: Mike Karels In-reply-to: Your message of Fri, 20 Jul 2007 10:55:18 -0700. <46A0F706.6020701@ironport.com> Date: Fri, 20 Jul 2007 17:39:28 -0500 Sender: karels@karels.net Cc: FreeBSD Net , Julian Elischer Subject: Re: Wierd networking. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: karels@karels.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 22:43:04 -0000 > I think that the possible courses of action are: > 1/ Ignore further incoming data, but ACK it. > (this is basically what the userland code does in this case) This could lead to indefinite data transfer, while misleading the sender into thinking the data are being delivered. > 2/ Stop ACKing the data, and let the other end time out. This seems like a waste of resources on both ends of the connection; both are doomed, but they both have to time out to go away. > 3/ Send a RST This is my choice, literally: I added the code to send a RST in this case sometime in the 1980s, after observing connections that hung with no reader, but with the writer in persist mode indefinitely. (That's choice 4: accept the data, let the receive buffer fill, then advertise a zero window forever.) Mike From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 22:57:36 2007 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8700316A41A for ; Fri, 20 Jul 2007 22:57:36 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outE.internet-mail-service.net (outE.internet-mail-service.net [216.240.47.228]) by mx1.freebsd.org (Postfix) with ESMTP id 67B5413C45B for ; Fri, 20 Jul 2007 22:57:36 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 20 Jul 2007 15:57:34 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 449CE125AE2; Fri, 20 Jul 2007 15:57:34 -0700 (PDT) Message-ID: <46A13DF8.6010202@elischer.org> Date: Fri, 20 Jul 2007 15:58:00 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Eli Dart References: <200707150237.l6F2bAgZ011098@redrock.karels.net> <469E0FFF.8070802@seclark.us> <20070720172021.8EA3D13C4B3@mx1.freebsd.org> <46A10063.9010902@elischer.org> <46A10860.50804@es.net> <46A13891.5040201@elischer.org> In-Reply-To: <46A13891.5040201@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 22:57:36 -0000 Julian Elischer wrote: > Eli Dart wrote: >> see below... >> >> Julian Elischer wrote: >>> Eli Dart wrote: >>>> >>>> >>>> Stephen Clark wrote: >>>> >>>>>> >>>>> So was any decision reached on this issue - will FreeBSD changed >>>>> to accept a packet on an interface that is larger than the mtu on >>>>> that interface? >>>> >>>> If possible, I'd like to see the ability to enforce interface MTU >>>> for received packets preserved in a sysctl if it is removed for the >>>> default config... In other words, something like: >>>> >>>> net.link.mtu_limits_received_pktsize = 0|1 >>>> >>>> Then, default it to 0 to preserve 4.x behavior. >>> >>> what would this achieve? >>> >>> Answering himself.. it MAY allow a driver to optimise a bit by not >>> needing to cope with the posibility of receiving jubo packets? I can >>> not think of any other reason.. (except to break networks that are >>> apparently working fine). >> >> The networks that are apparently working fine are most likely >> misconfigured, IMHO. >> >> Others have made a case for permitting an interface to accept as large >> a packet as it can, regardless of configured MTU. That's fine for >> theory. >> >> My operational experience leads me to a different place. If an >> interface receives a packet that is larger than its configured MTU, I >> would prefer that the packet be dropped as a giant and a giants >> counter incremented, regardless of whether the hardware can >> theoretically receive the packet. In modern networks, an MTU mismatch >> within a broadcast domain indicates a broken network, IMHO. If the >> devices in the network are configured to enforce MTU for both tx and >> rx, more problems get spotted during turnup, rather than surfacing >> later on as difficult-to-diagnose problems that users only call about >> after they are truly frustrated. And, if you have a giants counter >> (or input error counter) you can look at, it makes it straightforward >> to spot the problem. >> >> (one could also stretch a bit and say that enforcing MTU on rx might >> provide less surprise to code that consumes packets and has knowledge >> of the MTU setting of an interface.....unfortunately I don't know >> enough about the details of the network stack to know if this is a >> real concern) > > then we should have an MRU value. > mtu is mTu > > note that if the following code is what is doing it, it is only enabled in > DIAGNOSTIC mode anyhow. > > #ifdef DIAGNOSTIC > if (m->m_pkthdr.len > > ETHER_MAX_FRAME(ifp, etype, m->m_flags & M_HASFCS) && > (ifp->if_capenable & IFCAP_LRO) == 0) { > if_printf(ifp, "discard oversize frame " > "(ether type %x flags %x len %u > max > %lu)\n", > etype, m->m_flags, m->m_pkthdr.len, > ETHER_MAX_FRAME(ifp, etype, > m->m_flags & M_HASFCS)); > ifp->if_ierrors++; m_freem(m); > return; > } in 6.1 that would become: diff -u -r1.193.2.10 if_ethersubr.c --- if_ethersubr.c 4 Mar 2006 09:23:34 -0000 1.193.2.10 +++ if_ethersubr.c 20 Jul 2007 22:52:43 -0000 @@ -99,6 +99,8 @@ extern u_char aarp_org_code[3]; #endif /* NETATALK */ +static int mtu_is_mru = 0; + /* netgraph node hooks for ng_ether(4) */ void (*ng_ether_input_p)(struct ifnet *ifp, struct mbuf **mp); void (*ng_ether_input_orphan_p)(struct ifnet *ifp, struct mbuf *m); @@ -536,16 +559,18 @@ } eh = mtod(m, struct ether_header *); etype = ntohs(eh->ether_type); - if (m->m_pkthdr.len > - ETHER_MAX_FRAME(ifp, etype, m->m_flags & M_HASFCS)) { - if_printf(ifp, "discard oversize frame " - "(ether type %x flags %x len %u > max %lu)\n", - etype, m->m_flags, m->m_pkthdr.len, - ETHER_MAX_FRAME(ifp, etype, - m->m_flags & M_HASFCS)); - ifp->if_ierrors++; - m_freem(m); - return; + if (mtu_is_mru) { + if (m->m_pkthdr.len > + ETHER_MAX_FRAME(ifp, etype, m->m_flags & M_HASFCS)) { + if_printf(ifp, "discard oversize frame " + "(ether type %x flags %x len %u > max %lu)\n", + etype, m->m_flags, m->m_pkthdr.len, + ETHER_MAX_FRAME(ifp, etype, + m->m_flags & M_HASFCS)); + ifp->if_ierrors++; + m_freem(m); + return; + } } if (m->m_pkthdr.rcvif == NULL) { if_printf(ifp, "discard frame w/o interface pointer\n"); @@ -931,9 +982,11 @@ SYSCTL_DECL(_net_link); SYSCTL_NODE(_net_link, IFT_ETHER, ether, CTLFLAG_RW, 0, "Ethernet"); +SYSCTL_INT(_net_link_ether, OID_AUTO, MTUisMRU, CTLFLAG_RW, + &mtu_is_mru,0,"Allow MTU to limit recieved packet size"); #if defined(INET) || defined(INET6) SYSCTL_INT(_net_link_ether, OID_AUTO, ipfw, CTLFLAG_RW, ðer_ipfw,0,"Pass ether pkts through firewall"); #endif #if 0 possibly wrapped in #ifdef MTUISMRU so people could avoid the extra overhead. From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 22:59:18 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C9F516A417 for ; Fri, 20 Jul 2007 22:59:18 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.freebsd.org (Postfix) with ESMTP id C1F3A13C494 for ; Fri, 20 Jul 2007 22:59:17 +0000 (UTC) (envelope-from artemb@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so69482nfb for ; Fri, 20 Jul 2007 15:59:16 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=OHP8Zef1XKLr3vMNR3HYWCnAcvLUJ68F0YkUksHIVtYZxiW6Fgn+IV4rmKyMgUcucg+3baPKz542r2Zub9nFy8F/pVd9+92rhuVyZR9Oy7cWwW/EulIcD93zmPI5Y4AvizS/eYbuYLft+S2AVZmr81A+X032Ry+QPC86LpfYLPI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=PF3pPDLKIpbOrRwYD5ziVdd39AMMdLteCj6U5wttsIzcSoy3WwIb8w03dCEevwkaxcfbAobGeXiF8UtHU77lfrNv/x6UvmFz5+ssa/Qu2Qav7TSCZRw7aNscoDXChlo9+bF+jqD54S6pPr8blLV7+0SEEHGFDXZFPRW9ayYEdEU= Received: by 10.82.174.20 with SMTP id w20mr948577bue.1184970869945; Fri, 20 Jul 2007 15:34:29 -0700 (PDT) Received: by 10.82.105.7 with HTTP; Fri, 20 Jul 2007 15:34:29 -0700 (PDT) Message-ID: Date: Fri, 20 Jul 2007 15:34:29 -0700 From: "Artem Belevich" Sender: artemb@gmail.com To: "Eli Dart" In-Reply-To: <46A10860.50804@es.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200707150237.l6F2bAgZ011098@redrock.karels.net> <469E0FFF.8070802@seclark.us> <20070720172021.8EA3D13C4B3@mx1.freebsd.org> <46A10063.9010902@elischer.org> <46A10860.50804@es.net> X-Google-Sender-Auth: b2c5ad3c4af5d85e Cc: freebsd-net@freebsd.org, Julian Elischer Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 22:59:18 -0000 Here's one example where MTU!=MRU would be useful. Think of asymmetric bandwith-limited ADSL links. Lower MTU would allow lower TX latency for high priority packets when upstream is saturated, yet large MRU on the downstream would be great for downloads. Right now with 6.2 one has to trade off lower latency for faster download. --Artem From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 23:06:04 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48D3616A418 for ; Fri, 20 Jul 2007 23:06:04 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outW.internet-mail-service.net (outW.internet-mail-service.net [216.240.47.246]) by mx1.freebsd.org (Postfix) with ESMTP id 28DF113C474 for ; Fri, 20 Jul 2007 23:06:03 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 20 Jul 2007 16:06:03 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 1386B125A2A; Fri, 20 Jul 2007 16:06:03 -0700 (PDT) Message-ID: <46A13FF5.9070806@elischer.org> Date: Fri, 20 Jul 2007 16:06:29 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: karels@karels.net References: <200707202239.l6KMdSq4035780@redrock.karels.net> In-Reply-To: <200707202239.l6KMdSq4035780@redrock.karels.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Elischer , FreeBSD Net Subject: Re: Wierd networking. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 23:06:04 -0000 Mike Karels wrote: >> I think that the possible courses of action are: > >> 1/ Ignore further incoming data, but ACK it. >> (this is basically what the userland code does in this case) > > This could lead to indefinite data transfer, while misleading the sender > into thinking the data are being delivered. > >> 2/ Stop ACKing the data, and let the other end time out. > > This seems like a waste of resources on both ends of the connection; > both are doomed, but they both have to time out to go away. > >> 3/ Send a RST > > This is my choice, literally: I added the code to send a RST in this > case sometime in the 1980s, after observing connections that hung > with no reader, but with the writer in persist mode indefinitely. > (That's choice 4: accept the data, let the receive buffer fill, then > advertise a zero window forever.) > > Mike 5/ throw away SOME data and then resort to RST. the problem we ahve is that IE7 seems to send some data after the FIN is sent by the server, and complains when it gets the RST.\ The exact problem is when the FIN is because of a redirection (due to a 407, (proxy auth required), and IE aborts the whole transfer.. so: IE: "POST (or GET) bla bla" proxy: "407 (proxy auth required)"... FIN IE: "CR/LF" proxy: "RST" IE: [displays erro screen and fails to continue] We have changed the proxy to do a shutdown and keep receiving (and discarding) the data until it gets an EOF but I worry about DOS possibilities.. I think I may add code to make this only accept some limited amount of data before doing the close(). From owner-freebsd-net@FreeBSD.ORG Sat Jul 21 01:12:14 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A48C716A418 for ; Sat, 21 Jul 2007 01:12:14 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: from sigma.octantis.com.au (ns2.octantis.com.au [207.44.189.124]) by mx1.freebsd.org (Postfix) with ESMTP id 7254413C45E for ; Sat, 21 Jul 2007 01:12:14 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: (qmail 21402 invoked from network); 20 Jul 2007 19:45:33 -0500 Received: from 203-206-233-219.dyn.iinet.net.au (HELO localhost) (203.206.233.219) by sigma.octantis.com.au with (DHE-RSA-AES256-SHA encrypted) SMTP; 20 Jul 2007 19:45:32 -0500 Date: Sat, 21 Jul 2007 10:45:25 +1000 From: Norberto Meijome To: Robert Watson Message-ID: <20070721104525.44603382@localhost> In-Reply-To: <20070720180546.X39675@fledge.watson.org> References: <20070720145932.GP6053@more.net> <20070720180546.X39675@fledge.watson.org> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.14; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, "Eric L. Anderson" Subject: Re: Max NFS mounts for a FreeBSD client? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2007 01:12:14 -0000 On Fri, 20 Jul 2007 18:07:37 +0100 (BST) Robert Watson wrote: > > On Fri, 20 Jul 2007, Eric L. Anderson wrote: > > > What is the limit of NFS mounts a FreeBSD server can make and how do you > > modify this limit? > > > > The only reference I could find to this question on the FreeBSD lists is > > http://lists.freebsd.org/pipermail/freebsd-questions/2004-July/051947.html > > > > I have ran a similar test and the same thing happens after 420 NFS mounts. > > This is on both FreeBSD 6.0 and 6.2. > > > > We have recently run into a problem where we are bumping up against some > > kind of limit to the number of NFS mounts on our FreeBSD servers. > > Sounds a bit like something is running out of reserved ports to use -- the > credentials error may mean that a port number >1023 was used for an NFS > connection. Given that reserved ports start around 600, 420 is about the > right number of sockets to reach 1024. Hi, Reserved ports controlled by sysctl : net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.reservedlow: 0 although the 600 rwatson mentions seems to be this one: net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.portrange.lowlast: 600 You should be able to tweak these values - as long as you have ephemeral ports for the rest of your network activity, you should be ok, right? _________________________ {Beto|Norberto|Numard} Meijome "Discovery consists of looking at the same thing as everyone else does and thinking something different." Albert Szent-Gyorgyi, 1937 Nobel Prize in Physiology and Medicine I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From owner-freebsd-net@FreeBSD.ORG Sat Jul 21 04:00:11 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5D7B16A46B for ; Sat, 21 Jul 2007 04:00:11 +0000 (UTC) (envelope-from anderson@more.net) Received: from betaray.spg.more.net (betaray.spg.more.net [207.160.133.137]) by mx1.freebsd.org (Postfix) with ESMTP id BA40D13C483 for ; Sat, 21 Jul 2007 04:00:11 +0000 (UTC) (envelope-from anderson@more.net) Received: by betaray.spg.more.net (Postfix, from userid 1000) id E6ECD1A091B; Fri, 20 Jul 2007 23:00:09 -0500 (CDT) Date: Fri, 20 Jul 2007 23:00:09 -0500 From: "Eric L. Anderson" To: freebsd-net@freebsd.org Message-ID: <20070721040009.GB21336@more.net> References: <20070720145932.GP6053@more.net> <20070720180546.X39675@fledge.watson.org> <20070721104525.44603382@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070721104525.44603382@localhost> User-Agent: Mutt/1.5.11 Subject: Re: Max NFS mounts for a FreeBSD client? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2007 04:00:11 -0000 On Sat, Jul 21, 2007 at 10:45:25AM +1000, Norberto Meijome wrote: > On Fri, 20 Jul 2007 18:07:37 +0100 (BST) > Robert Watson wrote: > > > > Sounds a bit like something is running out of reserved ports to use -- the > > credentials error may mean that a port number >1023 was used for an NFS > > connection. Given that reserved ports start around 600, 420 is about the > > right number of sockets to reach 1024. > > > Hi, > Reserved ports controlled by sysctl : > > net.inet.ip.portrange.reservedhigh: 1023 > net.inet.ip.portrange.reservedlow: 0 > > although the 600 rwatson mentions seems to be this one: > > net.inet.ip.portrange.lowfirst: 1023 > net.inet.ip.portrange.lowlast: 600 > > You should be able to tweak these values - as long as you have > ephemeral ports for the rest of your network activity, you should be > ok, right? This sounds like we are on the right track. I verified via netstat that all ports from 600-1023 are being used for NFS after I run my test script. I can not change lowfirst to any higher amount. I did change lowlast from 600 to 1 and now I can mount more than 1000 NFS mounts. This is great but what kind of side effects am I introducing by making this change? -- Eric L. Anderson anderson@more.net From owner-freebsd-net@FreeBSD.ORG Sat Jul 21 08:04:29 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C5C316A418 for ; Sat, 21 Jul 2007 08:04:29 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from alf.aws-net.org.ua (alf.aws-net.org.ua [85.90.196.192]) by mx1.freebsd.org (Postfix) with ESMTP id A907D13C459 for ; Sat, 21 Jul 2007 08:04:26 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from [192.168.32.4] (aviko.aws-net.org.ua [192.168.32.4]) by alf.aws-net.org.ua (8.13.8/8.13.8) with ESMTP id l6L83gs0063517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 21 Jul 2007 11:03:47 +0300 (EEST) (envelope-from artem@aws-net.org.ua) Message-ID: <46A1BDDE.5080403@aws-net.org.ua> Date: Sat, 21 Jul 2007 11:03:42 +0300 From: Artyom Viklenko Organization: Art&Co. User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Artem Belevich References: <200707150237.l6F2bAgZ011098@redrock.karels.net> <469E0FFF.8070802@seclark.us> <20070720172021.8EA3D13C4B3@mx1.freebsd.org> <46A10063.9010902@elischer.org> <46A10860.50804@es.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-3.0 (alf.aws-net.org.ua [192.168.32.253]); Sat, 21 Jul 2007 11:03:52 +0300 (EEST) X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on localhost X-Virus-Status: Clean Cc: freebsd-net@freebsd.org, Julian Elischer Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2007 08:04:29 -0000 Artem Belevich wrote: > Here's one example where MTU!=MRU would be useful. > > Think of asymmetric bandwith-limited ADSL links. Lower MTU would allow > lower TX latency for high priority packets when upstream is saturated, > yet large MRU on the downstream would be great for downloads. > > Right now with 6.2 one has to trade off lower latency for faster download. > > --Artem You can prioritize small packets with ACKs, for example, by other techniques - ALTQ one of them. Unconditional lovering MTU even on ADSL tend to loss throughtput. And let's think about TCP MSS. When TCP connection establishes, TCP stack uses MTU as measure to choose MSS. Any two hosts, connected to single Layer2 network MUST use same MTU. Any other cases lead to hard-to-solve problems. This is all IMHO. But I would not like to see different MTU and MRU on my Ethernet interfaces! :) -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Sat Jul 21 08:06:09 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F1D516A417 for ; Sat, 21 Jul 2007 08:06:09 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from alf.aws-net.org.ua (alf.aws-net.org.ua [85.90.196.192]) by mx1.freebsd.org (Postfix) with ESMTP id A003C13C467 for ; Sat, 21 Jul 2007 08:06:06 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from [192.168.32.4] (aviko.aws-net.org.ua [192.168.32.4]) by alf.aws-net.org.ua (8.13.8/8.13.8) with ESMTP id l6L85lHN063556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 21 Jul 2007 11:05:47 +0300 (EEST) (envelope-from artem@aws-net.org.ua) Message-ID: <46A1BE5B.60509@aws-net.org.ua> Date: Sat, 21 Jul 2007 11:05:47 +0300 From: Artyom Viklenko Organization: Art&Co. User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Eli Dart References: <200707150237.l6F2bAgZ011098@redrock.karels.net> <469E0FFF.8070802@seclark.us> <20070720172021.8EA3D13C4B3@mx1.freebsd.org> <46A10063.9010902@elischer.org> <46A10860.50804@es.net> In-Reply-To: <46A10860.50804@es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-3.0 (alf.aws-net.org.ua [192.168.32.253]); Sat, 21 Jul 2007 11:05:47 +0300 (EEST) X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on localhost X-Virus-Status: Clean Cc: freebsd-net@freebsd.org, Julian Elischer Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2007 08:06:09 -0000 Eli Dart wrote: > > The networks that are apparently working fine are most likely > misconfigured, IMHO. > > Others have made a case for permitting an interface to accept as large a > packet as it can, regardless of configured MTU. That's fine for theory. > > My operational experience leads me to a different place. If an > interface receives a packet that is larger than its configured MTU, I > would prefer that the packet be dropped as a giant and a giants counter > incremented, regardless of whether the hardware can theoretically > receive the packet. In modern networks, an MTU mismatch within a > broadcast domain indicates a broken network, IMHO. If the devices in > the network are configured to enforce MTU for both tx and rx, more > problems get spotted during turnup, rather than surfacing later on as > difficult-to-diagnose problems that users only call about after they are > truly frustrated. And, if you have a giants counter (or input error > counter) you can look at, it makes it straightforward to spot the problem. > > (one could also stretch a bit and say that enforcing MTU on rx might > provide less surprise to code that consumes packets and has knowledge of > the MTU setting of an interface.....unfortunately I don't know enough > about the details of the network stack to know if this is a real concern) 100% agree! :) -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Sat Jul 21 16:24:49 2007 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B53916A41A for ; Sat, 21 Jul 2007 16:24:49 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: from smtpauth05.prod.mesa1.secureserver.net (smtpauth05.prod.mesa1.secureserver.net [64.202.165.99]) by mx1.freebsd.org (Postfix) with SMTP id C9F5813C46E for ; Sat, 21 Jul 2007 16:24:48 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: (qmail 30851 invoked from network); 21 Jul 2007 16:24:48 -0000 Received: from unknown (24.144.77.243) by smtpauth05.prod.mesa1.secureserver.net (64.202.165.99) with ESMTP; 21 Jul 2007 16:24:48 -0000 Message-ID: <46A2334F.2040302@seclark.us> Date: Sat, 21 Jul 2007 12:24:47 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; m18) Gecko/20010110 Netscape6/6.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eli Dart References: <200707150237.l6F2bAgZ011098@redrock.karels.net> <469E0FFF.8070802@seclark.us> <20070720172021.8EA3D13C4B3@mx1.freebsd.org> <46A10063.9010902@elischer.org> <46A10860.50804@es.net> In-Reply-To: <46A10860.50804@es.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, Julian Elischer Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Clark@seclark.us List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2007 16:24:49 -0000 Eli Dart wrote: >see below... > >Julian Elischer wrote: > > >>Eli Dart wrote: >> >> >>>Stephen Clark wrote: >>> >>> >>> >>>>So was any decision reached on this issue - will FreeBSD changed >>>>to accept a packet on an interface that is larger than the mtu on >>>>that interface? >>>> >>>> >>>If possible, I'd like to see the ability to enforce interface MTU >>>for received packets preserved in a sysctl if it is removed for the >>> default config... In other words, something like: >>> >>>net.link.mtu_limits_received_pktsize = 0|1 >>> >>>Then, default it to 0 to preserve 4.x behavior. >>> >>> >>what would this achieve? >> >>Answering himself.. it MAY allow a driver to optimise a bit by not >>needing to cope with the posibility of receiving jubo packets? I can >>not think of any other reason.. (except to break networks that are >>apparently working fine). >> >> > >The networks that are apparently working fine are most likely >misconfigured, IMHO. > >Others have made a case for permitting an interface to accept as large a >packet as it can, regardless of configured MTU. That's fine for theory. > >My operational experience leads me to a different place. If an >interface receives a packet that is larger than its configured MTU, I >would prefer that the packet be dropped as a giant and a giants counter > incremented, regardless of whether the hardware can theoretically >receive the packet. In modern networks, an MTU mismatch within a >broadcast domain indicates a broken network, IMHO. If the devices in >the network are configured to enforce MTU for both tx and rx, more >problems get spotted during turnup, rather than surfacing later on as >difficult-to-diagnose problems that users only call about after they are >truly frustrated. And, if you have a giants counter (or input error >counter) you can look at, it makes it straightforward to spot the problem. > >(one could also stretch a bit and say that enforcing MTU on rx might >provide less surprise to code that consumes packets and has knowledge of >the MTU setting of an interface.....unfortunately I don't know enough >about the details of the network stack to know if this is a real concern) > >Many thanks, > > --eli > > > > Hi Eli, You make some good points, however it is a change from previous FreeBSD behavior and is not required by any RFC's, plus it causes problems for some users. My $.02 Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-net@FreeBSD.ORG Sat Jul 21 16:28:31 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F68316A417 for ; Sat, 21 Jul 2007 16:28:31 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: from smtpout09.prod.mesa1.secureserver.net (smtpout09-04.prod.mesa1.secureserver.net [64.202.165.17]) by mx1.freebsd.org (Postfix) with SMTP id 679AA13C480 for ; Sat, 21 Jul 2007 16:28:31 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: (qmail 2359 invoked from network); 21 Jul 2007 16:28:29 -0000 Received: from unknown (24.144.77.243) by smtpout09-04.prod.mesa1.secureserver.net (64.202.165.17) with ESMTP; 21 Jul 2007 16:28:29 -0000 Message-ID: <46A2342C.1030205@seclark.us> Date: Sat, 21 Jul 2007 12:28:28 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; m18) Gecko/20010110 Netscape6/6.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Artyom Viklenko References: <200707150237.l6F2bAgZ011098@redrock.karels.net> <469E0FFF.8070802@seclark.us> <20070720172021.8EA3D13C4B3@mx1.freebsd.org> <46A10063.9010902@elischer.org> <46A10860.50804@es.net> <46A1BDDE.5080403@aws-net.org.ua> In-Reply-To: <46A1BDDE.5080403@aws-net.org.ua> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Artem Belevich , Julian Elischer Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Clark@seclark.us List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2007 16:28:31 -0000 Artyom Viklenko wrote: >Artem Belevich wrote: > > >>Here's one example where MTU!=MRU would be useful. >> >>Think of asymmetric bandwith-limited ADSL links. Lower MTU would allow >>lower TX latency for high priority packets when upstream is saturated, >>yet large MRU on the downstream would be great for downloads. >> >>Right now with 6.2 one has to trade off lower latency for faster download. >> >>--Artem >> >> > >You can prioritize small packets with ACKs, for example, by other >techniques - ALTQ one of them. >Unconditional lovering MTU even on ADSL tend to loss throughtput. > >And let's think about TCP MSS. When TCP connection establishes, >TCP stack uses MTU as measure to choose MSS. > >Any two hosts, connected to single Layer2 network MUST use >same MTU. Any other cases lead to hard-to-solve problems. > >This is all IMHO. But I would not like to see different >MTU and MRU on my Ethernet interfaces! :) > > > Yes but the mss is what the endpoints in the connection know about their own mtu's, at this point there is no knowledge of the mtu/mru's of intermediate routers. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-net@FreeBSD.ORG Sat Jul 21 16:37:12 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F23FA16A419 for ; Sat, 21 Jul 2007 16:37:12 +0000 (UTC) (envelope-from fox@verio.net) Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2.email.verio.net [129.250.36.42]) by mx1.freebsd.org (Postfix) with ESMTP id C6F0013C45B for ; Sat, 21 Jul 2007 16:37:12 +0000 (UTC) (envelope-from fox@verio.net) Received: from [129.250.36.64] (helo=dfw-mmp4.email.verio.net) by dfw-smtpout2.email.verio.net with esmtp id 1ICHx7-0001m4-1K for freebsd-net@freebsd.org; Sat, 21 Jul 2007 16:37:09 +0000 Received: from [129.250.40.241] (helo=limbo.int.dllstx01.us.it.verio.net) by dfw-mmp4.email.verio.net with esmtp id 1ICHx6-0003oE-UK for freebsd-net@freebsd.org; Sat, 21 Jul 2007 16:37:08 +0000 Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id 6D2EF8E296; Sat, 21 Jul 2007 11:37:05 -0500 (CDT) Date: Sat, 21 Jul 2007 11:37:05 -0500 From: David DeSimone To: freebsd-net@freebsd.org Message-ID: <20070721163704.GC13029@verio.net> Mail-Followup-To: freebsd-net@freebsd.org References: <200707150237.l6F2bAgZ011098@redrock.karels.net> <469E0FFF.8070802@seclark.us> <20070720172021.8EA3D13C4B3@mx1.freebsd.org> <46A10063.9010902@elischer.org> <46A10860.50804@es.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <46A10860.50804@es.net> Precedence: bulk User-Agent: Mutt/1.5.9i Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2007 16:37:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eli Dart wrote: > > The networks that are apparently working fine are most likely > misconfigured, IMHO. > > Others have made a case for permitting an interface to accept as large > a packet as it can, regardless of configured MTU. That's fine for > theory. It works okay in practice, too. You are correct about misconfigured networks. In my experience, the only reason to ever reduce the MTU is to work around a problem discovered in someone else's network (not my local segment). Fixing the problem by getting someone else to fix their network is generally too hard. If MTU == MRU was forced behavior, the viability of this workaround would be removed, one less tool in the toolbag, so to speak. - -- David DeSimone == Network Admin == fox@verio.net "It took me fifteen years to discover that I had no talent for writing, but I couldn't give it up because by that time I was too famous. -- Robert Benchley -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFGojYwFSrKRjX5eCoRAipgAJkBV6/IhmR8M+0o/bHviMFEvrfovQCcDP3w FoLZrDFkw5bJKqIwiLaW62E= =0KSA -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Sat Jul 21 17:06:13 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5695516A418 for ; Sat, 21 Jul 2007 17:06:13 +0000 (UTC) (envelope-from karels@redrock.karels.net) Received: from redrock.karels.net (redrock.karels.net [206.196.45.2]) by mx1.freebsd.org (Postfix) with ESMTP id 12A2013C481 for ; Sat, 21 Jul 2007 17:06:12 +0000 (UTC) (envelope-from karels@redrock.karels.net) Received: from redrock.karels.net (localhost.karels.net [127.0.0.1]) by redrock.karels.net (8.13.8/8.13.6) with ESMTP id l6LH2ukt039317; Sat, 21 Jul 2007 12:02:56 -0500 (CDT) (envelope-from karels@redrock.karels.net) Message-Id: <200707211702.l6LH2ukt039317@redrock.karels.net> To: Artyom Viklenko From: Mike Karels In-reply-to: Your message of Sat, 21 Jul 2007 11:03:42 +0300. <46A1BDDE.5080403@aws-net.org.ua> Date: Sat, 21 Jul 2007 12:02:56 -0500 Sender: karels@karels.net Cc: freebsd-net@freebsd.org, Artem Belevich , Julian Elischer Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: karels@karels.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2007 17:06:13 -0000 > Any two hosts, connected to single Layer2 network MUST use > same MTU. Any other cases lead to hard-to-solve problems. I'd have to disagree. In fact, I'd say that any two hosts on the same L2 network must use the same MRU. In particular, if a host choses to use a lower MTU, if that also lowers the MRU, *that* is the cause of interoperability problems. David DeSimone wrote: } You are correct about misconfigured networks. In my experience, } the only reason to ever reduce the MTU is to work around a problem } discovered in someone else's network (not my local segment). Fixing } the problem by getting someone else to fix their network is generally } too hard. If MTU == MRU was forced behavior, the viability of this } workaround would be removed, one less tool in the toolbag, so to speak. Exactly. In our local labs, we also reduce the MTU to test PMTU discovery. Requiring MRU == MTU makes this more difficult. True, it's a contrived situation, but as you say, one less tool in the toolbag. Mike From owner-freebsd-net@FreeBSD.ORG Sat Jul 21 17:50:06 2007 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6653016A49A for ; Sat, 21 Jul 2007 17:50:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 37E8313C49D for ; Sat, 21 Jul 2007 17:50:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l6LHo57W086498 for ; Sat, 21 Jul 2007 17:50:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l6LHo5N4086497; Sat, 21 Jul 2007 17:50:05 GMT (envelope-from gnats) Date: Sat, 21 Jul 2007 17:50:05 GMT Message-Id: <200707211750.l6LHo5N4086497@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Andy Farkas" Cc: Subject: Re: kern/112654: [pcn] Kernel panic upon if_pcn module load on a Netfinity 5000 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andy Farkas List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2007 17:50:06 -0000 The following reply was made to PR kern/112654; it has been noted by GNATS. From: "Andy Farkas" To: bug-followup@FreeBSD.org, keve.mail.poliod.hu@FreeBSD.org Cc: Subject: Re: kern/112654: [pcn] Kernel panic upon if_pcn module load on a Netfinity 5000 Date: Sun, 22 Jul 2007 03:28:33 +1000 Panic also happens on FreeBSD 7.0-CURRENT (built Sat Jul 7 06:52:24 EST 2007). Mentioned was a possible fix in src/sys/dev/mii/nsphy.c, but note that ukphy is being used. -andyf From owner-freebsd-net@FreeBSD.ORG Sat Jul 21 19:23:10 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F20A16A418 for ; Sat, 21 Jul 2007 19:23:10 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 577F313C442 for ; Sat, 21 Jul 2007 19:23:10 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 061A94798B; Sat, 21 Jul 2007 15:23:10 -0400 (EDT) Date: Sat, 21 Jul 2007 20:23:09 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Eric L. Anderson" In-Reply-To: <20070721040009.GB21336@more.net> Message-ID: <20070721202012.C83919@fledge.watson.org> References: <20070720145932.GP6053@more.net> <20070720180546.X39675@fledge.watson.org> <20070721104525.44603382@localhost> <20070721040009.GB21336@more.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Max NFS mounts for a FreeBSD client? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2007 19:23:10 -0000 On Fri, 20 Jul 2007, Eric L. Anderson wrote: > On Sat, Jul 21, 2007 at 10:45:25AM +1000, Norberto Meijome wrote: >> On Fri, 20 Jul 2007 18:07:37 +0100 (BST) >> Robert Watson wrote: >>> >>> Sounds a bit like something is running out of reserved ports to use -- the >>> credentials error may mean that a port number >1023 was used for an NFS >>> connection. Given that reserved ports start around 600, 420 is about the >>> right number of sockets to reach 1024. >> >> Reserved ports controlled by sysctl : >> >> net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.reservedlow: >> 0 >> >> although the 600 rwatson mentions seems to be this one: >> >> net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.portrange.lowlast: 600 >> >> You should be able to tweak these values - as long as you have ephemeral >> ports for the rest of your network activity, you should be ok, right? > > This sounds like we are on the right track. I verified via netstat that all > ports from 600-1023 are being used for NFS after I run my test script. > > I can not change lowfirst to any higher amount. I did change lowlast from > 600 to 1 and now I can mount more than 1000 NFS mounts. This is great but > what kind of side effects am I introducing by making this change? The issue here, presumably, is that each NFS client mountpoint has (and requires) a unique socket, which means a unique TCP/IP or UDP/IP tuple with its respective server endpoint. This is used to demux replies, etc. With TCP/IP NFS mounts, it should be possible, in principle, to be quite a bit more conservative in the use of tuples, as reusing a source IP and port number is only a problem if there's a collision with another mountpoint using identical destination IP and port. It could be that NFS, perhaps with a bit of help from the TCP layer, could be more agressive about reusing existing local port numbers rather than using a new one for every mountpoint. I'm not sure what would be involved infrastructure-wise here, and obviously care would have to be taken not to break UDP/IP mounts. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Sat Jul 21 19:24:09 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBA5116A420 for ; Sat, 21 Jul 2007 19:24:09 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id C6CE413C45A for ; Sat, 21 Jul 2007 19:24:09 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 8094E4798A; Sat, 21 Jul 2007 15:24:09 -0400 (EDT) Date: Sat, 21 Jul 2007 20:24:09 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Eric L. Anderson" In-Reply-To: <20070721040009.GB21336@more.net> Message-ID: <20070721202327.T83919@fledge.watson.org> References: <20070720145932.GP6053@more.net> <20070720180546.X39675@fledge.watson.org> <20070721104525.44603382@localhost> <20070721040009.GB21336@more.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Max NFS mounts for a FreeBSD client? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2007 19:24:10 -0000 On Fri, 20 Jul 2007, Eric L. Anderson wrote: > I can not change lowfirst to any higher amount. I did change lowlast from > 600 to 1 and now I can mount more than 1000 NFS mounts. This is great but > what kind of side effects am I introducing by making this change? The risk, btw, is that those reserved ports may no longer be available for other use, as they may collide with other services you might want to have, especially if those services want to bind INADDR_ANY. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Sat Jul 21 22:30:32 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D9B816A558; Sat, 21 Jul 2007 22:30:28 +0000 (UTC) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (unknown [IPv6:2001:5a8:4:2140:21b:fcff:fe24:feef]) by mx1.freebsd.org (Postfix) with ESMTP id E35CB13C469; Sat, 21 Jul 2007 22:30:17 +0000 (UTC) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.14.1/8.14.1) with ESMTP id l6LMUCam000665; Sat, 21 Jul 2007 15:30:17 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.14.1/8.14.1/Submit) id l6KItiwK014161; Fri, 20 Jul 2007 11:55:44 -0700 (PDT) (envelope-from peter@wemm.org) X-Authentication-Warning: overcee.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: freebsd-current@freebsd.org Date: Fri, 20 Jul 2007 11:55:44 -0700 User-Agent: KMail/1.9.6 References: <20070709234401.S29353@odysseus.silby.com> <20070710132253.GJ1038@void.codelabs.ru> <20070710202028.I34890@odysseus.silby.com> In-Reply-To: <20070710202028.I34890@odysseus.silby.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707201155.44573.peter@wemm.org> Cc: Andre Oppermann , current@freebsd.org, Robert Watson , net@freebsd.org Subject: Re: FreeBSD 7 TCP syncache fix: request for testers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2007 22:30:32 -0000 On Tuesday 10 July 2007, Mike Silbersack wrote: > On Tue, 10 Jul 2007, Eygene Ryabinkin wrote: > > Can't say that I am pushing much traffic through my box, but after > > applying your patch and rebuilding the kernel I am still seeing the > > messages like > > ----- > > TCP: [209.132.176.NNN]:NNN to [144.206.NNN.NNN]:NNN tcpflags > > 0x19; syncache_expand: Segment failed SYNCOOKIE > > authentication, segment rejected (probably spoofed) TCP: > > [201.90.65.NNN]:NNN to [144.206.NNN.NNN]:NNN; syncache_timer: > > Response timeout ----- > > But what had changed is that the lines with the 'syncache_timer' > > started to appear. There were no such lines prior to the patch, > > only the 'failed SYNCOOKIE' ones. > > The "syncache_timer: Response timeout" message means that the > syncache sent a SYN-ACK response four times, but still didn't receive > a response. This probably means that someone tried using a port > scanner or was going through a faulty firewall. We'll definitely > have to take that log message out before 7.0 is released. > > The fact that you're still getting the syncache_expand message tells > me that there's another bug which I have not yet fixed still present. I get hundreds of these messages within a few hours of boot: [...] TCP: [127.0.0.1]:65491 to [127.0.0.1]:1128 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [127.0.0.1]:64055 to [127.0.0.1]:1128 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [10.0.0.85]:1665 to [10.0.0.3]:139 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [127.0.0.1]:60995 to [127.0.0.1]:1128 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [10.0.0.84]:56408 to [10.0.0.3]:22 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [127.0.0.1]:53469 to [127.0.0.1]:1128 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [127.0.0.1]:52446 to [127.0.0.1]:1128 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) [...] How on earth can localhost be spoofing itself? This is getting quite absurd. :-( Port 1128 is an x10 daemon FWIW. There is just one single client, run from cron every few minutes. There is no congestion on the listen socket. It is an extremely quiet and low volume server. I don't have your patch installed, but am just about to. I mentioned it because you commented that this is a different problem below. > My suspicion is that the "Segment failed SYNCOOKIE authentication" > message is the aftereffect of FreeBSD 7 randomly dropping TCP > connections, and not the problem itself. My theory is that the > connection is silently dropped, without the other endpoint knowing. > That other endpoint then sends an ACK packet, which is then believed > to be a syncookie. Since it is not, it obviously fails the > verification. > > Finding that bug is my next goal. > > > But the patch received only half a day of testing, so I will > > continue the tests and will inform you if some other information > > will be available. Up to date I don't see problems that had > > appeared without the patch, but they tend to show up after a > > midnight ;)) > > > > Thank you! > > Thanks for testing, I look forward to hearing how things work for > you. I'll give your patch a shot and see if it improves things at all. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5