netdev - Re: amplifying qdisc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200713095228.5867b7ec@hermes.lan>
Date:   Mon, 13 Jul 2020 09:52:28 -0700
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     Russell Strong <russell@...ong.id.au>
Cc:     netdev@...r.kernel.org
Subject: Re: amplifying qdisc

On Sun, 12 Jul 2020 11:40:01 +1000
Russell Strong <russell@...ong.id.au> wrote:

> On Wed, 8 Jul 2020 23:26:34 -0700
> Stephen Hemminger <stephen@...workplumber.org> wrote:
> 
> > On Thu, 9 Jul 2020 16:10:34 +1000
> > Russell Strong <russell@...ong.id.au> wrote:
> >   
> > > Hi,
> > > 
> > > I'm attempting to fill a link with background traffic that is sent
> > > whenever the link is idle.  To do this I've creates a qdisc that
> > > will repeat the last packet in the queue for a defined number of
> > > times (possibly infinite in the future). I am able to control the
> > > contents of the fill traffic by sending the occasional packet
> > > through this qdisc.
> > > 
> > > This is works as the root qdisc and below a TBF.  When I try it as a
> > > leaf of HTB unexpected behaviour ensues.  I suspect my approach is
> > > violating some rules for qdiscs?  Any help/ideas/pointers would be
> > > appreciated.    
> > 
> > Netem can already do things like this. Why not add to that
> >   
> 
> Hi,
> 
> Tried doing this within netem as follows; but run into similar
> problems.  Works as the root qdisc (except for "Route cache is full:
> consider increasing sysctl net.ipv[4|6].route.max_size.") but not under
> htb.  I am attempting to duplicate at dequeue, rather than enqueue to
> get an infinite stream of packets rather than a fixed number of
> duplicates. Is this possible?
> 
> Thanks
> Russell

HTB expects any thing under it to be work conserving.