* Re: [Bloat] small rural wireless ISP
2011-11-08 19:05 [Bloat] small rural wireless ISP Andrew Hammond
@ 2011-11-08 19:39 ` Dave Taht
2011-11-09 23:12 ` david
1 sibling, 0 replies; 3+ messages in thread
From: Dave Taht @ 2011-11-08 19:39 UTC (permalink / raw)
To: Andrew Hammond; +Cc: bloat
[-- Attachment #1: Type: text/plain, Size: 4315 bytes --]
On Tue, Nov 8, 2011 at 8:05 PM, Andrew Hammond <
andrew.george.hammond@gmail.com> wrote:
> My friend owns and operates a small ISP that serves a small town and the
> surrounding rural area.
>
> His current setup is wireless routers in bridge mode.
>
>
Heh. I would suspect he has scaling problems.
> As a first step, I'd like to move him to an OSPF routed network. I've
> never built an OSPF network, can you guys please recommend a good page for
> reading up about it?
>
Cero's default routing protocol is babel, and is nearly zero setup. Change
the ip addresses with a sed script, disable nat, plug them into each other.
ospf and ospf6 are in the optional quagga package as are most other routing
protocols. Years ago I started working with ospf but gave up on it due to
requiring two different daemons, two different kinds of packets, and two
different conf files for ipv4 and ipv6. It was too large to run both in
16MB of RAM, too. That latter problem is not a problem on larger routers.
I later went to olsr and then batman and currently babel.
There is seemingly big support for ospf and olsr within the theorists in
the homenet working group.
Babel, OLSR, and batman have respectable metrics for wireless networks.
OSPF, not so much.
Babel is 'RIP on speed'. I'm not going to go into babel's evolution (or
religion) here, but I would like it if more people understood that being
able to effectively route P2P links is crucial for wireless behavior....
http://www.pps.jussieu.fr/~jch/software/babel/
>
> I'd like for the majority of the routers to be running cerowrt, however
> that would require at a minimum external antenna connectors.
>
Ubiquity's products mostly use the same chipset, and have available
external antennas or an all in one unit such as the nanostation M5.
There are a lot of other products that use the same chipset, too.
> I understand that the only hardware supported by cerowrt (so far) is the
> Netgear WNDR3700v2. Is it (reasonably) possible to attach external antennas
> to these routers?
>
The ideas of cerowrt are implementable in just about any hardware, but it's
the ath9k chipset that matters at the moment, not the brand, and only
because it's the most 'open source' of the wifi stacks we had to choose
from when we started.
I've periodically built a cerowrt version for the nano-m5, merely stripping
out the named daemon support to gain enough flash for an 8MB system. It
only takes a few minutes to make the change to the filesystem and package
database and compile a version specific to that.
Whenever cerowrt is 'baked' - which seems an increasingly distant goal of
late - it will be easy to slam it on a couple dozen brands
That said it remains our intent to push up everything possible into openwrt
itself as it stablizes.
I (or rather some enthusiasts did) pulled apart a 3800 and it showed the
standard detachable tiny antenna connectors on the motherboard, and there
are plenty of converters from that to a N connector - but ubiquity's gear
already does that for you.
>
> Finally, I'm wondering how much interest there would be in some form of
> access to this network for the purposes of analyzing or proving concept
> code.
>
I certainly would like to have a long distance wireless network to play
with again, and tools that monitored latency via things like snmp...
I had had a mesh network using the nanostation M5s up in nicaragua 2 years
back. got beat by bufferbloat. The ath9k series of drivers is fixed now
'enough' to go and deploy that again but I still seriously think active
queue management is required now-adays to keep flows in hand.
As another example I'd help build a gigE wireless backbone (wiline.com)
around the bay area 6+ years back (has it been that long?). When I left the
US they'd provisioned voice over the same backbone. When I came back,
they'd had to go to a dual stack for voice support. Bufferbloat again...
>
> Sincerely
> Andrew
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
>
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
[-- Attachment #2: Type: text/html, Size: 5939 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread