Forgot your password?
typodupeerror

Comment: The home router market is a an ongoing disaster (Score 5, Interesting) 228

by mtaht (#45118463) Attached to: D-Link Router Backdoor Vulnerability Allows Full Access To Settings
It's not just simple backdoors like the dlink one that are a problem.

There is a systemic complete and total regard for basic tenets of security in nearly the entire home router/cpe market.

Start with crypto - no hwrng and a known "less than ideal" version of /dev/random to feed your "secure" wpa and ssh sessions.

Worse:

There is no privilege separation in most routers, which was ok when they were single function devices - BUT: not ok, when vulnerability via services like samba can be used to root most of the top 10 current home routers:

http://securityevaluators.com/content/case-studies/routers/soho_service_hacks.jsp

Once an attacker p0wns your home gateway they can change your dns to malicious sites, as dnschanger did:

http://www.dcwg.org/

or have it participate in botnets, or inflict further attacks on unsuspecting devices both inside and outside your firewall, or sniff your traffic - there is no security when your front door is left wide open.

What nearly every home router and cpe manufacturer is shipping is **rotware**, running 4-7 year old kernels with known CVEs, and 10 year old versions of critical services like dnsmasq. You'd think that new 802.11ac devices available for this christmas might have some modern software on it, but just to pick out a recent example - the "new" netgear nighthawk router runs Linux 2.6.36.4 and dnsmasq 2.15, according to their R7000 gpl code drop -

http://kb.netgear.com/app/answers/detail/a_id/2649

Brand new hardware - 4+ and 10 year old software respectively.

It's unfair of me to pick on Netgear, every router I've looked at this christmas season has some major issues.

Right now, the only current hope for decent security in home routers is in open, modern, and maintained firmware. And I wish the manufacturers (and ISPs, AND users, and governments) understood that, and there was (in particular) a sustainable model for continuous updates and upgrades as effective as android's in this market. I don't care if it came from taxation, isp fees, or built into the price of the device - would you willingly leave your networks' front door open if you understood the consequences?

Rotten routers with closed source code, and no maintenance, are a huge security risk, and they are holding back the ipv6 transition, (and nearly all current models have bufferbloat, besides)

How can the dysfunctional edge of the Internet be fixed?

Comment: Dedications help (Score 3, Interesting) 186

by mtaht (#41650179) Attached to: Ask Slashdot: Dedicating Code?
I lost two friends and my father this year. I dedicated this release of cerowrt ( http://cero2.bufferbloat.net/cerowrt/credits.html ) to them. Most of the machines we have are named after someone that has passed, for example our main build box is named after http://en.wikipedia.org/wiki/John_Huchra It helped a lot to channel them all as we struggled to get the releases out. And, surprisingly, making ice cream, with liquid nitrogen as the coolant, has got to be a healing ritual, around here.
Linux

+ - Linux-3.3: Making a dent in bufferbloat?->

Submitted by
mtaht
mtaht writes "Has anyone, besides those that worked on byte queue limits, and sfqred, had a chance to benchmark networking using these tools on the linux 3.3 kernel... in the real world? A dent, at least theoretically, seems to be have made in bufferbloat, and now that the new kernel and new iproute2 are out, should be easy to apply in general (e.g. server/desktop) situations..."
Link to Original Source

Comment: Re:Easy solution? (Score 1) 124

by mtaht (#38253394) Attached to: Bufferbloat: Dark Buffers In the Internet

What Jim and the bufferbloat.net's group of volunteers have accomplished in a year - on nearly no money - boggles my mind.

Today's commentary on slashdot is a hundred times more clueful than it was last year - and a few days back Byte Queue Limits went into linux's net-next tree, which fixes much of the bloat problems that exist at the ethernet driver layer.

What has been discussed as 'Time in Queue' limits in the higher level schedulers is still awaiting a clean way to avoid layer violations. I've been too distracted by the BQL merge to pursue that next phase of fixes.

What we could have done this year with *some money* - nowhere near the amounts you describe above! - could have been amazing, and as for the next year, well, who knows? It is going to take many man-years worth of effort to make the internet responsive again.

And even with that said, to have harnessed the powers of hundreds first, now thousands, of talented minds, to help solve the bufferbloat problem - has been a far more effective - and wonderful! thing than all the money in the world.

Comment: Re:Use a real DNS server (Score 3, Informative) 212

by mtaht (#36639552) Attached to: Telstra Starts Implementing Australian Censorship Scheme
Nearly every Linux machine ships with named (bind9) available and often, even turned on, in a caching-only configuration. To use it by default you just disable /etc/dhcp/dhclient's domain-name-servers request and point your resolv.conf to localhost. By doing this you get NXdomain back, too... and your local cache of dns entries is likely to be more performant than an ISPs 10s of ms away for cached entries. You can also run dnssec, if you so choose. Latest versions of bind can do dnssec, you can enable it with one line in the conf file. Ever since multiple services started messing with DNS a decade ago... returning broken queries, pointing to ad sites, not doing ipv6, not returning mx records, etc... I've run my own dns server. Now that dns is being mis-used for censorship, perhaps more will rebell. As servers go, in memory it's rather small...

Comment: Re:Buffer Bloat (Score 3, Interesting) 99

by mtaht (#35579448) Attached to: Google Spends $1 Million For Throttling Detection

The original gatech study showed not only bufferbloat, but enormous variation of base latencies in the first mile for different brands of cable modem as well as for different kinds of DSL and wireless technologies.

Slides: http://www.caida.org/workshops/isma/1102/slides/aims1102_ssundaresan.pdf

Some commentary: http://gettys.wordpress.com/2011/02/17/caida-workshop/

I look forward to the followup!

Comment: Re:Buffer bloat is (not) an illusion... (Score 1) 121

by mtaht (#35326534) Attached to: Got (Buffer) Bloat?

Sort of in answer to both of your questions the bufferbloat.net servers are configured as follows:

http://www.bufferbloat.net/projects/bloat/wiki/Dogfood_Principle

trying at every point to make sure http 1.1 actually got used.

We survived today's slashdotting. Handily.

That said, your points are well made. SPDY is part of the chromium browser and looks to have some potential.

In my case, I like the idea of smarter - and eventually sctp-enabled - proxies, especially on wireless hops. See thread at:

https://lists.bufferbloat.net/pipermail/bloat/2011-February/000068.html

Comment: Re:Keeping big buffers but managing them better (Score 1) 121

by mtaht (#35326430) Attached to: Got (Buffer) Bloat?

Please feel free to write some code. Writing a new qdisc for Linux and BSD is not very hard.

Writing a good qdisc, insanely so.

That said, I tend to feel that time-stamping more packets and doing more guessing may make sense, as does concepts in TCP vegas.

But: Before starting, read these:

http://pollere.net/Pdfdocs/bcit_6.2001.pdf Kathleen Nichols - who proved to Van Jacobson that RED was wrong -

And Van Jacobson: http://pollere.net/Pdfdocs/QrantJul06.pdf

Comment: Re:what it is (Score 3, Informative) 121

by mtaht (#35326380) Attached to: Got (Buffer) Bloat?

re:"Interesting problem for dd-wrt"

Agreed.
We are throwing efforts at both the mainline kernel and openwrt.
Openwrt is foundational for dd-wrt and several other (commercial) distributions of Linux on the router. I have a large set of debloated routers already, I'm just awaiting further work on the eBDP algorithm to make better....

http://www.bufferbloat.net/projects/bloat/wiki/Experiment_-_Bloated_LAGN_vs_debloated_WNDR5700

re: "using pings"
httpping is a much saner approach than ping, in many cases. Get it from:

http://www.vanheusden.com/httping/

re: RED & AQM

SFB and CHOKEe are in the debloat-testing kernel, as is eBDP.
RED 93 isn't going to work. nRED may. Experimentation and scripts highly desired. See the bloat and bloat-devel mailing lists for discussions.

Also:

http://www.bufferbloat.net/projects/bloat/wiki/Dogfood_Principle

Also:

I've seen some VERY interesting behavior with tcp vegas over bloated connections.

http://www.bufferbloat.net/projects/bloat/wiki/Experiment_-_TCP_cubic_vs_TCP_vegas

Comment: Re:what it is (Score 1) 121

by mtaht (#35326294) Attached to: Got (Buffer) Bloat?
Well... yes, I'm one of the first 144 on bufferbloat.net But jg defined Bufferbloat so well, that the packet traces I'd seen on my wisp6 design in South America, suddenly made complete and total sense, when I first saw his back in November. I'd had no idea what I was dealing with was actually a worldwide probem. but thank you for the thanks. I blush.

Comment: Re:Who pointed it out? (Score 1) 121

by mtaht (#35326262) Attached to: Got (Buffer) Bloat?
I think you are referring to an early draft of an article by Eric Raymond, which was wildly incorrect on this point, which was thoroughly discussed on the bloat mailing list. See the incredibly long thread starting at: https://lists.bufferbloat.net/pipermail/bloat/2011-February/000050.html There is a newer, fully corrected piece coming out soon. In the meantime, consider the words of Van Jacobson, Vint Cerf, and others. Carefully. https://lists.bufferbloat.net/pipermail/bloat/2011-February/000108.html http://www.bufferbloat.net/projects/bloat/wiki/Quotes

Overdrawn? But I still have checks left!

Working...