From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 5C3F321F1C1 for ; Fri, 12 Jul 2013 10:00:20 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id a11so13486588iee.6 for ; Fri, 12 Jul 2013 10:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=fo40tiG3so8xzT4YFbou7SUs7ywEzr+RCDUyJANdpkM=; b=V7KPyBNr9DDINnvdv8ohRdnWEhAW/Yo14d6+e9fO7MTFpsmVZ6Hfb6p2A0dJ1/A48I iAQwSII2hS2WtiM8ffPgpOnX5KPtK0lPZwjYLnHxiMqEsqqQEbWGRPUjCNVHKT+EfIQm 5fG/+I4YTBCjSGao0K8Jc1U5aVlxTWeLjtp0CLWzAO9EII6DFqJKeObQSpj0zeokZ5tH Zspx/VPIgA7Z2vhQ4nS53514wT+yPdk2Y+0CtEdUDVcv70nCHdAYLkp5/r7TFsS2jhHF dIc1nF5b6gTeqmracOP+p1fXmqzZfNa//49dFaAuobiRx53TpmUzR4o63RAspHwajO0w +Irw== MIME-Version: 1.0 X-Received: by 10.50.88.7 with SMTP id bc7mr1212624igb.37.1373648419620; Fri, 12 Jul 2013 10:00:19 -0700 (PDT) Received: by 10.64.98.162 with HTTP; Fri, 12 Jul 2013 10:00:19 -0700 (PDT) In-Reply-To: <1373648057.10804.29.camel@edumazet-glaptop> References: <1373564673.4600.55.camel@edumazet-glaptop> <1373568848.4600.66.camel@edumazet-glaptop> <20130712113413.4b601800@redhat.com> <1373642001.10804.18.camel@edumazet-glaptop> <1373648057.10804.29.camel@edumazet-glaptop> Date: Fri, 12 Jul 2013 13:00:19 -0400 Message-ID: From: Dave Taht To: Eric Dumazet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: codel@lists.bufferbloat.net, Jesper Dangaard Brouer Subject: Re: [Codel] hardware multiqueue in fq_codel? X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 17:00:20 -0000 On Fri, Jul 12, 2013 at 12:54 PM, Eric Dumazet wro= te: > On Fri, 2013-07-12 at 18:36 +0200, Sebastian Moeller wrote: > >> >> Question, what stops the same attacker to also fudge the TOS bits = (say to land in priority band 0)? Just asking... > > This kind of thing is filtered before those packets arrive to the tx > queue where pfifo_fast is plugged ;) Agree. > > TOS is properly checked/rewritten when alien packets enter your network. Agree. > > People caring with this do their own classification using iptables or tc > filter rules. Linux wifi automagically tosses stuff currently based on CSX diffserv values into what it thinks is the appropriate mq driven hardware queue. I've already shown how damaging it is to use 802.11e and the hardware VI and VO queues from a wifi client elsewhere, so regard this as a separate (and harder) problem from finding a pfifo_fast replacement. (and kernel build mechanism for making it a default) > > > > _______________________________________________ > Codel mailing list > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html