Re: virtual wireless interfaces / WDS

>>>>> "cs" == Cliff Skolnick <[email protected]> writes:

    cs> 2) Create a dynamic interface for any other system running
    cs> hostap,

I think this is wds(4) and is also part of the Young proposal.

    cs> I don't really see the value of an individual interface per
    cs> client. [...]  RTS/CTS behavior 

The value was discussed earlier, and is not composed in its entirity
of RTS/CTS behavior.

    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.  Ricochet of Los Gatos, 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.  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.

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>.''

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

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.

    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.

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.

    cs> and use application encryption.

and I'd rather see everything use opportunistic IPsec with
certificates obtained through DNSSEC, because a lot of encryption
frameworks are weak in practice because the endpoints are not named in
a secure fashion.  But this is not the right place to have this
argument.

-- 
Le fascisme est la dictature ouverte de la bourgeoisie.
		-- Georg Dimitrov
--
*bsd wireless list, a bawug thing <http://www.bawug.org/>
[un]subscribe: http://lists.bawug.org/mailman/listinfo/bsd-wireless/