Re: virtual wireless interfaces / WDS

I'd actually suggest something a little different.  To help with mesh 
networking I would like to see hostap modified to do the following.

1) Just behave like the current wiX for all non-hostap wireless clients.

2) Create a dynamic interface for any other system running hostap, 
these are what could be bridged together (damn the 802.11 spec).  This 
would be a point to point link that would be configured by some daemon 
that could add or remove it from a bridge group.

I don't really see the value of an individual interface per client.  
Sure there are individual configuration option that could be done, but 
if you make your client behave different in RTS/CTS behavior that would 
be difficult to predict behavior.  Different WEP keys might be useful, 
but in a community wireless environment I'd rather see things open and 
use application encryption.

Cheers,
Cliff

On Thursday, Apr 17, 2003, at 01:21 US/Pacific, M. Warner Losh wrote:

> In message: <[email protected]>
>             Miles Nordin <[email protected]> writes:
> : 802.11 is this weirdass third kind of thing.
>
> That's why it is hard to know what the right thing to do here is.
>
> :    mwl> I'd prefer that the staN appear and disappear on their own 
> and
> :    mwl> that the daemon would just react,
> :
> : one of the annoying things with dynamically appearing and 
> disappearing
> : BSD devices is, if sta147 appears, disappears, and reappears, you
> : don't know if it's the same sta147, it's a different sta147, or you
> : don't know if it's the same or different.  Sometimes I think this
> : 3-case information is ascertainable by the driver but there is no way
> : to pass it up.  maybe that is more with mounted disks than network
> : devices, but if you run into that problem unexpectedly while working
> : on this it'd be nice if you solved it cleanly for everyone else, too.
>
> This is a well known problem.  However, in FreeBSD pccard devices
> behave this way and people are used to it.  NetBSD tries to make sure
> they are the same, but I have so little experience with NetBSD's
> numbering that I can't comment on it.
>
> One can work around the problem by never reusing a number I suppose,
> but I don't like that.  The sta are just tags and one should ask the
> sta what it is before you configure it.  Unlike xl0 or wi0, which one
> could assume one knows what physical device they are, the stas are
> definitely a dynamic concept and we shouldn't try to impose a static
> world view on them.  sta0 might be joe's laptop today, and mike router
> tomorrow or next reboot.
>
> :     dy> if the wi(4) belongs to a bridge, it should add all of its 
> sta
> :     dy> to the bridge?
> :
> : Does the abstraction support hostap drivers that can create more than
> : one nwid, setting different parameters, and IP addresses, for each?
>
> I'm not sure that all devices' firmware supports having multiple
> nwid.  The packet engine devices certainly would, however.
>
> Warner
> --
> *bsd wireless list, a bawug thing <http://www.bawug.org/>
> [un]subscribe: http://lists.bawug.org/mailman/listinfo/bsd-wireless/
>
--
"You can never solve a problem at the level at which it was created. 
You have to go to at least one level beyond."
- Albert Einstein

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