From: Dave Taht <dave.taht@gmail.com>
To: cerowrt-devel@lists.bufferbloat.net,
Juliusz Chroboczek <jch@pps.jussieu.fr>,
Gabriel Kerneis <kerneis@pps.jussieu.fr>,
cerowrt@lists.bufferbloat.net
Subject: [Cerowrt-devel] potentially dropping mesh networking from cerowrt rc8 [#201]
Date: Tue, 6 Dec 2011 17:39:03 +0100 [thread overview]
Message-ID: <CAA93jw4dfR0KCc3XEgucrdVj=VA=+oWA_mfctqXGc_Mnhrr7+Q@mail.gmail.com> (raw)
This is the second of a series of emails discussing things that may be
dropped from the next release of cerowrt, and is intended to open the
discussion, only.
The goal is to find better ways to focus on fixing bufferbloat.
While I personally find babel very useful, as well as AHCP, convincing
anyone that these two bleeding edge technologies are worthwhile on
places like the homenet mailing list is an incredible struggle. The
consensus there appears to be leaning towards ospf, not that anyone on
that list has bothered to test that, either. We have had the ability
to use ospf in the system since day one as an optional package.
Routing, actually, is not needed in simple setups.
Other problems:
1) The AHCP package in openwrt keeps breaking. It broke of the late
rc7-smoketest6-ish series, and so far as I know, hasn't been fixed.
1a) The gui interface, even when the package was working, is equally
problemantic
2) Firewalling remains REALLY problematic with both babel and AHCP.
More often than not, you end up with stuff
that doesn't work.
3) Packet loss as a metric appears to not be a good metric anymore.
4) As much as I enjoy mesh networking, the few people that have tried
to set it up independently that I know of, have all failed.
And lastly,
5) As pointed out during a test in brussels, cerowrt itself has become
too complex even for someone familiar with openwrt to deal with it.
So with no real users of these subsystems in the field, these two
packages can be safely dropped.
There were some positive benefits to being able to test ad-hoc mode,
having the interfaces available at all times, etc, but deleting the
extra interfaces and firewall complexity would help.
While I believe that a pure mesh environment works a LOT better than a
pure 'as we know networking today' environment, however, the attempt
thus far,
of merging the 'best of' the two, seems to be worse, than either.
This eliminates having to fix bugs #252, #110, #112, #201, and I've
never got around to mentioning how much I was hoping for dhcp/ahcp
integration.
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
next reply other threads:[~2011-12-06 16:39 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-06 16:39 Dave Taht [this message]
2011-12-06 17:09 ` Shane Turner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAA93jw4dfR0KCc3XEgucrdVj=VA=+oWA_mfctqXGc_Mnhrr7+Q@mail.gmail.com' \
--to=dave.taht@gmail.com \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=cerowrt@lists.bufferbloat.net \
--cc=jch@pps.jussieu.fr \
--cc=kerneis@pps.jussieu.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox