Re: [Bloat] talking at linux plumbers in portugal next week

[Dave Taht <dave.taht@gmail.com>]

On Tue, Sep 3, 2019 at 8:10 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
> Dave Taht <dave.taht@gmail.com> writes:
>
> > On Tue, Sep 3, 2019 at 7:45 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> >>
> >> Dave Taht <dave.taht@gmail.com> writes:
> >>
> >> > On Tue, Sep 3, 2019 at 5:23 AM Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> >> >>
> >> >> On Mon, 2 Sep 2019, Dave Taht wrote:
> >> >>
> >> >> > with copy-pasted parameters set in the 90s - openwrt's default, last I
> >> >> > looked, was 25/sec.
> >> >>
> >> >> -A syn_flood -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 25/sec --limit-burst 50 -m comment --comment "!fw3" -j RETURN
> >> >> -A syn_flood -m comment --comment "!fw3" -j DROP
> >> >>
> >> >> Well, it's got a burst-size of 50. I agree that this is quite
> >> >> conservative.
> >> >>
> >> >> However, at least in my home we're not seeing drops:
> >> >>
> >> >> # iptables -nvL | grep -A 4 "Chain syn_flood"
> >> >> Chain syn_flood (1 references)
> >> >>   pkts bytes target     prot opt in     out     source               destination
> >> >>   2296  113K RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* !fw3 */
> >> >>      0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* !fw3 */
> >> >>
> >> >> But you might be right that in places with a lot more clients then this
> >> >> might indeed cause problems.
> >> >
> >> > Well, *I* long ago had upped those params by 10x and don't see syn
> >> > drops either on my backbone. But I rather suspect the rest of the
> >> > world just copy-pasted it. It should scale as a function of bandwidth,
> >> > I suppose, or get updated as a side effect of setting QoS - or just
> >> > get bumped up. Start a bug over with openwrt? Take a hard look at
> >> > other firewall designs?
> >>
> >> FWIW:
> >>
> >> # iptables -nvL syn_flood
> >> Chain syn_flood (1 references)
> >>  pkts bytes target     prot opt in     out     source               destination
> >>  195K   12M RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* !fw3 */
> >>     0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* !fw3 */
> >>
> >> # ip6tables -nvL syn_flood
> >> Chain syn_flood (1 references)
> >>  pkts bytes target     prot opt in     out     source               destination
> >>   396 41508 RETURN     tcp      *      *       ::/0                 ::/0                 tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* !fw3 */
> >>     0     0 DROP       all      *      *       ::/0                 ::/0                 /* !fw3 */
> >>
> >> rebooted this box today; don't seem to have hit the limit thus far,
> >> though... This is on a gigabit link.
> >
> > Hmm. Try to trigger it with --te=upload_streams=200 ?
>
> Sure, that triggers it:
>
> # iptables -nvL syn_flood
> Chain syn_flood (1 references)
>  pkts bytes target     prot opt in     out     source               destination
>  197K   12M RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* !fw3 */
>   275 16480 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* !fw3 */
>
>
> And I get tons of errors from netperf failing to start up.
>
> However, the protection is only actually enabled for the INPUT chain;
> i.e., I had to use the router itself as the netperf target to trigger
> the rule. So not sure a rule such as this would be the cause of your
> coffee shop failures?

Good point. I think in the cerowrt case I'd enabled it for all chains
and then noticed, and bumped it up. Limiting syn attempts to the
router itself makes more sense than doing it on the forward path.

The coffee shop tests were fun, but I(we) needed more rigor when doing
them. What I'd typically do is go in,
get on the wifi, start 6 minutes worth of tests, get in line, get
coffee... I would feel a twinge of guilt when I'd
start seeing heads pop up from their laptops while running the rrul
test, but in two cases I managed to talk to
the owner, help 'em get QoS configured right on their router, show'd
'em the difference, and got a free meal out of it...

So, it was only discovering that I'd had that 30% rejection figure via
the stats on my osx box that I started speculating
as to the cause(s), last week. The other big fear is that because OSX
is always attempting to negotiate ECN, that that's a cause.

A bit more rigor about this and it could turn into a good paper or
blog entry, and it's good to get out more for the
sake of science, with table service!




>
> This is with the default openwrt config, BTW:
>
>
> config defaults
>         option syn_flood '1'
>
>
> -Toke



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740