From owner-freebsd-stable@FreeBSD.ORG Sun Dec 31 09:20:56 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 290DA16A403 for ; Sun, 31 Dec 2006 09:20:56 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 8FD9F13C442 for ; Sun, 31 Dec 2006 09:20:55 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id kBV9Khch047449; Sun, 31 Dec 2006 06:20:43 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: Sam Leffler Date: Sun, 31 Dec 2006 07:20:43 -0200 User-Agent: KMail/1.9.3 References: <200612282002.11562.joao@matik.com.br> <200612301926.57736.joao@matik.com.br> <45972EF6.9040506@errno.com> In-Reply-To: <45972EF6.9040506@errno.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200612310720.43293.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: ath0 timeout problem - again X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2006 09:20:56 -0000 On Sunday 31 December 2006 01:31, Sam Leffler wrote: > >>> I really do not know what this event means (ether type 5e4), for my > >>> understandings it is vague in the source, so I am lost here > >> > >> Seems pretty clear: it's the type field extracted from the ethernet > >> header of the oversized packet. =A0A quick check of sys/net/ethernet.h > >> shows no such ETHERTYPE defined. =A0So something in your network is > >> transmitting packets that either being rx'd incorrectly or, more likel= y, > >> corrupted in transit. > > > > good so far, point here is that we can not limit that someone tx this > > kind of packets but should find a way that this traffic do not DoS the > > AP. > > > > ipfw accepts 0x5e4 but at the end it does not get this packages > > changing mtu on any interface does not change a thing > > > > > > when we track the oversized packages they we found they are coming from > > nat servers where wingate and similar softwares are running, when we cut > > them out the mentioned traffic stopps and the AP does not interrupt > > service anymore > > So the packet is real and it's being dropped at the 802.3 layer as it > should. =A0If the printf is the problem remove it or rate limit it. =A0I > think it should be rate-limited or just stuck under a debug flag but > I'll leave that to someone else. =A0Alternatively we can enforce the mtu > in the ath driver and drop it there. the problem is that the ath card stops working rendering the machine useless I do not get this problem with a wi prism card, when I switch to a wi card = I=20 get some wi timeout events but the card does not stop as the ath does when I run the server with ath card not as bridge but as a gateway it also= =20 does not stop working and the mentioned packages do also exist on the netwo= rk=20 but are not even mentioned/noticed by the AP enforcing a mtu limit and dropping the larger packages sounds as a good sta= rt=20 for me. If you could be so kind and make such a patch to try it out I get t= he=20 results in a day or two since I have machines which hang several times a da= y. =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br