From owner-freebsd-net@FreeBSD.ORG Sat Sep 6 15:18:24 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7660816A4BF for ; Sat, 6 Sep 2003 15:18:24 -0700 (PDT) Received: from mail.lambdabroadband.com (mail.lambdabroadband.com [81.17.78.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52D9343FDF for ; Sat, 6 Sep 2003 15:18:21 -0700 (PDT) (envelope-from sb.mailinglist@lambdabroadband.com) Received: from blackbox ([81.17.78.11]) by mail.lambdabroadband.com (Kerio MailServer 5.6.5); Sat, 6 Sep 2003 23:18:22 +0100 Message-ID: <012e01c374c4$d3d3a1e0$0b4e1151@blackbox> From: "Colin Watson" To: "Bruce M Simpson" , References: <002201c3749d$c8cf4460$0b4e1151@blackbox> <20030906212549.GP1417@spc.org> Date: Sat, 6 Sep 2003 23:18:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Subject: Re: Packet loss problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Colin Watson List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2003 22:18:24 -0000 I don't believe so. We pay for a leased connection - so it's not supposed to be filtered. I'll have a dig around tho. One other question, is their any way to statically map an IP to a MAC (user who keeps chainging their IP when they shouldn't), but prevent them associating the MAC with any other IP? .Or am I gonna have to dig thru some ipfw rules ? Thanks Colin ----- Original Message ----- From: "Bruce M Simpson" To: "Colin Watson" Cc: Sent: Saturday, September 06, 2003 10:25 PM Subject: Re: Packet loss problem > On Sat, Sep 06, 2003 at 06:39:12PM +0100, Colin Watson wrote: > > / 33104 broadcast/multicast datagrams dropped due to no socket " which seems an inordinatly high amount. There are no drops due to full socket buffers, although I have recompiled the kernel with nmbclusters=8192 and Maxusers=1024 (to increase number of available sockets - kern.ipc.maxsockets to 9391), still the loss occurs. Any suggestions, and could someone explicitly explain what "broadcast/multicast datagrams dropped due to no socket" means. > > As Pete points out this unusually high 'no socket' figure could be due to > packets being received for a service you don't run. Beefing up the > number of PCBs you can have won't have any effect there if that is the case. > > Also it could be due to a socket application not binding to INADDR_ANY to > pick up undirected broadcasts (they don't get delivered to interface bound > ports). Of course this is probably not likely to affect your application > if you're explicitly unicasting traffic. But if you intend to receive > multicasts this could be the case. > > Are you filtering anything, or could your upstream be filtering anything? > > BMS > _______________________________________________ > 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" >