Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 8 May 2002 12:04:52 +0930
From:      Greg 'groggy' Lehey <grog@FreeBSD.org>
To:        "M. Warner Losh" <imp@village.org>
Cc:        brooks@one-eyed-alien.net, chris@masto.com, jhay@icomtek.csir.co.za, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/share/man/man4 wi.4
Message-ID:  <20020508120452.G10930@wantadilla.lemis.com>
In-Reply-To: <20020506.233735.118306874.imp@village.org>
References:  <20020506.211945.111478471.imp@village.org> <20020506222616.B1977@Odin.AC.HMC.Edu> <20020507145834.P63106@wantadilla.lemis.com> <20020506.233735.118306874.imp@village.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Monday,  6 May 2002 at 23:37:35 -0600, Warner Losh wrote:
> In message: <20020507145834.P63106@wantadilla.lemis.com>
>             "Greg 'groggy' Lehey" <grog@FreeBSD.org> writes:
>> On Monday,  6 May 2002 at 22:26:17 -0700, Brooks Davis wrote:
>>> On Mon, May 06, 2002 at 09:19:45PM -0600, M. Warner Losh wrote:
>>>> In message: <20020507115643.N75198@wantadilla.lemis.com>
>>>>> Interesting question.  You only need to create an IBSS once per IBSS
>>>>> network.  I now have definitive proof that the station which creates
>>>>> the IBSS doesn't do very much: I've taken that station out of the net,
>>>>> and the other two machines can still talk to each other.  But I can
>>>>> see issues when more than one station creates the IBSS: the net could
>>>>> partition itself into two different IBSSs, so I suspect we should keep
>>>>> the distinction, though the term "master" seems less appropriate.
>>>>
>>>> Yes, but you need to keep recreating it from time to time, as these
>>>> things time out.  "master" will be there until you convince OpenBSD to
>>>> change, so quit harping on that.
>>>
>>> My intented implementation is that adhoc will mean ibss-master in
>>> 5.0.
>>
>> I think this would be *really* confusing.  I can see people setting up
>> ad-hoc interfaces on different releases with identical commands, and
>> wondering why they can't interoperate.  If we change adhoc, I think we
>> should get rid of it altogether, not change the meaning.
>
> You just totally contradicted what you said in email yesterday where
> you approved of this idea. 

That was before I realised that it was already in use.  I thought this
was something new that you were planning to implement that way.

> The reason that we want to harmonize what ad-hoc means in current is
> that it means different things to different drivers in -stable right
> now.  For lucent cards, that have the old firmware, and many prism2
> cards it means "demo ad-hoc mode".  For lucent cards with new
> firmware and some prism and symbol cards, it means "ibss mode".  And
> for all cisco cards (supported by the an driver), it means "ibss
> mode".  It is a horrible confusion of rats nets of differing
> meanings, none of which seem to make sense (and I may have gotten at
> least one of them wrong).  Having it be an alias for "ibss-master"
> in current is the only sane thing to do.

By no means.  There are plenty of sane things to do.  Maybe splitting
into "ibss" and "create-ibss" would be better, for example.

>>> If there are devices out there that are so totally broken that they
>>> screw things up when they are allowed to create an IBSS and someone
>>> else has done it first, we'll deal with the problem then.
>>
>> I don't think that's the issue.  I've been using IBSS for some time,
>> and once I knew what I was doing, I had no problems.
>
> You must not be using symbol cards then, because it is an issue with
> them.  The wi driver in stable does support symbol cards in ibss mode,
> but doesn't support them creating an ibss network when they need to.

Hmm.  No, I'm using Orinocos.

Greg
--
See complete headers for address and phone numbers

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020508120452.G10930>