Hi Dave,
On Jan 27, 2013, at 04:28 , Dave Taht wrote:
> A couple things:
>
> It has long been my plan to integrate simple_qos (call it ceroshaper) into
> the gui, and have a test run automatically to determine the uplink/downlink
> bandwidth, and store that in upnp.
Any idea of how to determine link speed by a script? As I intend to
disable upnp it would be great if the link speeds still be stored somewhere
and/or manually overridden. I want a firewall since I do not trust a number of
devices too much, like an iPod and a nexus7 and want to keep them under
supervision, so allowing them to pierce the firewall makes me feel a bit
uneasy. Then again, Skype and friends figured out how to do NAT traversal
without upnp so disabling it will only buy me a little more control with a lot
more hassle. Any expert on the security tradeoff involved with UPNP willing to
give their opinion on this question.
In related news:
https://community.rapid7.com/community/infosec/blog/2013/01/29/security-flaws-in-universal-plug-and-play-unplug-dont-play
So maybe my uneasyness has some grounding in reality, Mind you, I have not yet
tested whether cerowrt is affected (and I doubt that, since the linked exploit
requires old ). Related question should cero's firewall drop tcp port 5000 and
udp port 1900 connection requests on the wan interface to put in belt and
suspenders for UPNP remote exploits? But how does the interact with using
cerowrt as secondary router? (Being away from the router I can not easily
check/change the firewall settings…)
>
> The gui interface stuff has long defeated me, as well as finding enough
> servers to be the backend portion of the test. as for the latter portion, I
> have got a couple linode boxes up and hope to get some more boxes from
> another resource. as for the gui, I'm just hopeless there.
>
> As for the shaper script...
>
> One thing I notice right now is that an awful lot of stuff ends up in the
> background bin for some reason.
Now I am away from my router and just equipped with an e-mailer, that
is typically when I am most dangerous ;), but when you send out non-working
examples earlier I wondered whether to check individual TOS bits would you not
have to mask off all other bits?
>
> Similar things are happening on (unshaped) wifi. There's a bug there I think.
>
> It's been my hope to finish cake (simple_qos poured into C and made more 32
> bit cpu oriented) for a month now. I hope that will fix the background bin
> thing as it does full diffserv classification - but I don't know when I'll be
> done, so it would be nice to figure out what's going on.
Ah, is this to have a drop in replacement for pfifo_fast?
>
> One thing that testing (actually kathie) revealed last week is that 1024
> nfq_codel flows may be excessive. 32 works pretty good, actually, and
> provides a defense indirectly, against bittorrent eating your life. Why that
> works is that codel works pretty good against one or a few flows in a single
> bin, and 32 bins limits the amount of delay that can be injected into the
> system that is unmanagable via codel. I'd been trying for "perfect isolation"
> between flows, but that meant that in an extreme overload situation with 100s
> of flows, and low bandwidth, delay could get out of hand.
Question, is not the extreme condition round robin through all other
flows? So the worst case latency might arise if all flows are eligible for one
full MTU packet ;at (measly) DSL uplink speeds of say 512Kbit/sec that means
each sent package will hog the line for ~23ms, so even at 32 queues the worst
case latency would be 31 * 23 = 713 ms. So no more than 4 queues can be
serviced routinely before the system will exceed target (assuming the default
100ms, but I might have that wrong)
>
> Heck, 16 bins might be enough. Don't know.
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt:
> http://www.teklibre.com/cerowrt/subscribe.html
> _______________________________________________
> Cerowrt-devel mailing list
> [email protected]
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
