Re: virtual wireless interfaces / WDS

On Friday, Apr 18, 2003, at 11:14 US/Pacific, Miles Nordin wrote:
>     cs> To help with mesh networking
>
> huh?
>
> First of all, it's kind of a sore point to me that you community
> wireless folk have been mindblowingly unable to come up with even the
> start of a mesh routing protocol.

There are a number of implementations that I know are running, mobile 
mesh and locus world come to mind.  More importantly Jonathan Moore has 
been improving upon mobile mesh for a while.  I've talked with him and 
other about it quite a bit and I feel that it meets most needs.  RSPF 
also has promise.

One issue is the lack of support in OSs for dynamic interfaces, one 
thing I think is getting addressed here.

The second issue is that a total mesh network does not scale, although 
mesh networking can really help extending networks into problematic 
coverage areas.  IMHO you'll always need a backbone that is designed 
and relies on point to point links, but I'll admit this is where I and 
a number of folks in the community network crowd disagree.  Time will 
tell.

Third we've been busy with many things, but trust me we are moving 
forward.  Not fast enough for you, you are welcome to help out or start 
your own group.

> Ricochet of Los Gatos

Not totally a mesh, there were backhauls at 2.3Ghz if I remember.  They 
did try to do a total mesh though.  I actually base my opinions on mesh 
on the lessons learned at Ricochet.

>  Mesh
> Networks of Maitland, Florida, and the US military all have viable
> wireless mesh routing protocols, yet the ``open'' community doesn't
> even have a start.

Do some research and look at mobile mesh.

>  Their idea of routing is to use DHCP with a short
> lease.  so, what I mean by ``sore,'' is I'd be more comfortable with
> this camp dictating the design of the wi driver if they'd actually
> produced something in the last two or three years they've been talking
> about mesh routing.  viva la revolucion and all that, but let's be
> honest about this.  Your comrades have made minimal progress, and
> there's correspondingly little evidence you have any idea what the
> hell you're doing.

indeed...thanks for your support.  What have you done?

As on of the founders of the Apache httpd project I often? ask myself 
why did that open source effort take off so fast and CWN feels it is 
standing still at times  The most logical answer that I came up with is 
that most of us were getting paid by various companies when we were 
hacking Apache.

I wish more people would pay the cwn folks to build things, and there 
is some progress in this area but not enough IMHO.  I agree with you 
that we need to do more.

> The Young sta(4) proposal, OTOH, doesn't attempt to design a mesh
> routing protocol, but rather to pass more information up to an
> application-level routing daemon, hoping that maybe with a better API
> more people will have the skills (ex., non-kernel developers) and
> inclination to approach the problem.  This seems like a much more
> humble approach to me, than saying ``don't add this sta(4) feature
> because it'll distract us from our mesh routing efforts, which will
> look like THIS: <blah>.''

Actually I was hoping to prioritize, I don't mind additional features.  
And yes I have code that would use the interface.  As for doing it 
myself I've done a half dozen kernel network drivers before, none open 
source but for sunos and solaris back in the days when I worked at Sun. 
   Enhancing the wi driver has been something on my list to do for over 
a year now.  But I'll admit that list is really long and there are many 
tasks in front of it.  I think mesh networks are great, but there are 
more important things that need to happen first.  BAWRN uses point to 
point links, as do other designs I have worked on myself for various 
projects.  IMHO backbone first, mesh second and I appreciate the fact 
that others may disagree.

> Second, how does *removing* support for sta *help* mesh routing?

never said remove it, said I don't see the use for it.  I was giving my 
opinion as a "customer" of new features interface.  Why do you have a 
problem with that?  If you have a problem with CWN in general we do 
invite you to work with us and address it.

> Third, 802.11 is very weak on avoiding interference.  As much as
> possible you want one AP per broadcast geography-domain and channel.
> I think it's realistically impossible to maintain both this
> requirement and seamless coverage, but with wds it's booted out the
> door.  so, you want us to use more APs and fewer stations.  I think
> the opposite approach is better from an interference standpoint.  As
> much as possible, radios should be stations and obey an AP's
> time-slicing.  Providing wds-only means if you want regular
> bridge-like functionality, both endpoints have to be APs.  This is an
> arbitrary and harmful constraint.

Agreed on 802.11 limitations, but it's what we have today.  That's why 
I just want a "point to point" interface to appear to any bridge that 
wants to join the group.  It does not have to be WDS, hell it could be 
some custom BSD thing and long as it is open source and it appears as a 
point to point interface like the tun, gif, or ppp driver.  In fact if 
I see tons of traffic going between two nodes in a network that I ran I 
would think about a dedicated point to point link on another channel or 
band and using the same interface would make things easy to do the 
switch.

>
>     cs> WEP [...] but in a community wireless environment I'd rather
>     cs> see things open
>
> 1. you should not cripple the low-level design of the system to agree
>    with fleeting interpretations of narrow-minded political goals.

Again, just giving my opinion..knowing quite well open source folks 
will do whatever they want to do.   I don't think anyones goals here 
are narrow minded.

>
> 2. other things are settable per-station, such as transmit power and
>    IP address.  or are these things irrelevant in a community wireless
>    setting, too?  It seems to me that assigning stations individual IP
>    addresses, or moving them between two bridges, would blend very
>    nicely with your captive portal strategies.

Agreed these are all nice things...but I would rather have an API where 
I could just refer to a station by its mac address and not have to look 
up which random staN it is right now.  In fact I would be chasing a 
moving target if I had to do a lookup then issue a command.  And before 
I comment on how unit numbers are assigned to sta devices I'll wait to 
see an implementation that can handle 2 or 3 wi interfaces.

No matter how I look at it there is much in common between what is 
being offered and what I would like to see.  Enough so that the effort 
to get what I want would be drastically reduced I look forward to 
seeing anything.  In fact I'll put $'s on the line here and I get 
something I can use I'll send the author at least a $1,000 check - 
seriously.

Cheers,
Cliff

--
"An eye for an eye and the whole world ends up blind."
- Mahatma Gandhi

--
*bsd wireless list, a bawug thing <http://www.bawug.org/>
[un]subscribe: http://lists.bawug.org/mailman/listinfo/bsd-wireless/