For those that aren't on the LW Meshap User list

[Helen Anderson]

I know there are a few on this google group that can't get subscribed to
the LW Mesh AP list.

Here is a posting from there from Mark Williams

------------------------------------------------

Finally! Truly open source Atheros drivers.

This development may just be what those of you whom wanted the Atheros
support in the OSS version of meshap
have been waiting for.

http://madwifi.org/wiki/About/ath5k

I am told that the news that there is drivers out doesn't make any
difference to most of us here unless it is developed as LW is based on
Slackware old Linux Kernal.

Helen

--
www.wireless.southwitham.net
Skype:helenander
8442...@voiptalk.org

[Nick halln@clannet.co.uk]

Hi,

I have recieved this from Quorvos concerning the new Mad wifi driver
and kernel development:

The current kernel is 2.4.20; we have test-beds working with both
2.4.23 and 2.6 kernels, and one of those will be released as an
upgrade within the next few months. We will incorporate the recent
madwifi drivers when they get to commercially acceptable stability
under the conditions our clients usually use, including ad-hoc, fixed
datarates, longer distances, etc. Currently we use madwifi-old
together with several custom-written support modules to give us the
stability and performance we need.

These guys seem serious to me.
No signs yet of infrastructure meshing soon.

Nick

On Oct 3, 8:09 am, Helen Anderson <helen-ander...@southwitham.com>
wrote:

> 84424...@voiptalk.org

[Tom Anderson]

Hi Nick and All,

msdist .co.uk website for the new pc engines alix board.

Apart from IkarusOS, which we recommend, other Operating Systems are available for ALIX boards:
LINUX: LEAF, ME2000 (Linux wireless node based on LEAF), WRAPCOP, GNAP (Gentoo Linux based), Amsel, Pebble Linux, Metrix Pebble, Voyage Linux, AstLinux (including Asterisk PBX), Locustworld MeshAP, Meshnode FREEBSD: Monowall (FreeBSD based), pfSense COMMERCIAL: StarOS, MITC MeshAP for Willox, Wisper MeshAP adaptation, Qorvus Qcode™

Been visiting some websites.
For "mesh" they would appear to be using the a,b,g atheros for the backhaul "meshing " it,  and b for local distribution and not meshing this bit.
So two radio's and two antenna per box , then work out how many meshed hops you can go and still deliver good bandwidth at the local point.
Sticking strictly to a shoestring budget , a mini -itx repeater can add radio's on the ethernet side for the backhaul turning them into gateways. Each new gateway can run on different ESSIDs so no more having to lock to mac for clients or clients switching from one to the other indiscriminately.
£30 quidish for a Buffalo to handle this , beats buying anything else , and redesigning your mini-itx.
Wiana stays the same for management and authentication or you could try Wumps.

For best effect run backhaul on "a" or channel 14 "g"

Meshing could be AODV or OLSR or WDS

Tom

[Nick halln@clannet.co.uk]

Hi Tom and all,

I agree largely with most of that Tom, if I understand correctly,
except the money restraint bit.

You are correct to point out that meshing is only working really on
the backhaul side as this needs to kept separate for very good
reasons. It seems only the Brits had this 'strange' idea of a single
radio on a single channel for both backhaul and clients; while the
yanks started off with dual radios from start. I don't think our
American friends have any idea what we are all grumbling about as
adhoc mesh on OSS with atheros has always worked!!! With the 'single'
radio approach as soon as you have long backhaul links (like ours)
then a small amount of noise ruins your backhaul speed. In addition
twin radios have almost no hop losses providing you switch channel for
each hop, and we have proven this with two meshboxes back to back.

There is not much benefit in running 'g' in a mixed b/g client side,
normally experienced, except where you are in a notspot, like ours,
and we control frequency allocation to a large degree, so, for us pure
g is possible.

We WERE planning a network topology exactly as you describe, with the
remote gateway idea.This retains WIANA, but it is crude, and is not an
integrated solution, which has always been the big attraction of
MeshAP. I thing the Qorvos route offers a fully routed topology,
avoiding remote gateways.
Talking with Qorvos it seems deployment can be staged with careful
design by starting with your core repeaters. Then you already should
achieve a big advantage. We think once we have proven that we will
expect our clients to pay for the improvement of a full deployment
thereafter. We will set aside 1 channel as 'g 'only, for the staged
deployment, which will also be meshed, but for redundancy purposes
only. This will run on top of our backhaul on a different channel on
the core repeaters and our original channel will be left for legacy b
devices until they are all gone. It maybe by then that 11n arrives and
we only have 2 useable channels anyway.

When the interference at our gateways becomes intolerable we will
switch to 11a

We have decided that we will try 1 Qorvos license and put it in a
Compaq and see if twin radios are possible in our existing hardware.
If the two radios mesh, and this fails, we will look at using two
boxes with an extra Ethernet card. as Tom described a few posting ago.

Time to put my money where my mouth is.

Regards,

Nick

On Oct 4, 7:40 pm, Tom Anderson <t...@swbb.us> wrote:
> Hi Nick and All,
>
> msdist .co.uk website for the new pc engines alix board.
>
> Apart from IkarusOS, which we recommend, other Operating Systems are
> available for ALIX boards:
> LINUX: LEAF, ME2000 (Linux wireless node based on LEAF), WRAPCOP, GNAP
> (Gentoo Linux based), Amsel, Pebble Linux, Metrix Pebble, Voyage Linux,
> AstLinux (including Asterisk PBX), Locustworld MeshAP, Meshnode FREEBSD:
> Monowall (FreeBSD based), pfSense COMMERCIAL: StarOS, MITC MeshAP for

> Willox, Wisper MeshAP adaptation, Qorvus Qcode^(TM)

> >> 84424...@voiptalk.org- Hide quoted text -
>
> - Show quoted text -