[Commotion-dev] static BSSID?

L. Aaron Kaplan aaron at lo-res.org
Thu May 17 15:16:53 UTC 2012


On May 13, 2012, at 4:08 AM, Hans-Christoph Steiner wrote:

> 
> My guess is that this is not a good idea to include in the madwifi driver, since it goes against how the Ad-hoc standard is supposed to work, and it would hinder interoperability with other implementations outside of madwifi (other Linux drivers, Windows, BSD, Mac OS X, etc.)
> 
> But for mesh use, this makes perfect sense from what I can see since more mesh nodes on the same SSID mean a better network, versus with standard Ad-hoc, multiple networks with the same SSID would mean interference, both on the wifi level, and things like multiple DHCP servers, etc.
> 
Maybe we mean the same thing but it came across differently or I am simply nit-picking now.
But as it is written here:
"what I can see since more mesh nodes on the same SSID mean a better network" 

is  not true

I would say the more nodes on *different* channels but somehow connected to each other (LAN), the better the network.

Use cable whenever you can :) It keeps those darn radio waves contained hehe.

I think I have a very very neat solution for this. Can show it to you next time we meet.

a.

> .hc
> 
> On May 12, 2012, at 9:57 PM, Josh King wrote:
> 
>> BSSID in an ad-hoc network definitely should be statically set in order 
>> to avoid network cell partitioning problems. I remember that hashing 
>> the SSID was a proposed solution for this in the madwifi driver, but I 
>> don't know if it was ever implemented (I vaguely recall some objection 
>> to this as a bad idea, but I cannot for the life of me find the 
>> reference to that argument, or think myself of why it might not be a 
>> good idea). In any event, there's an old patch posted for the madwifi 
>> driver that provides some sample code that could provide some guidance 
>> w/ respect to hashing:
>> 
>> http://permalink.gmane.org/gmane.linux.drivers.madwifi.devel/4787
>> 
>> On Sat 12 May 2012 09:02:40 PM EDT, Jeremy Lakeman wrote:
>>> No, we haven't chosen a hash function at all.
>>> 
>>> On Sun, May 13, 2012 at 3:27 AM, Hans-Christoph Steiner
>>> <hans at guardianproject.info> wrote:
>>>> 
>>>> That's a really nice, tight idea.  I like it.  Do you have an algorithm for it yet?
>>>> 
>>>> .hc
>>>> 
>>>> On May 11, 2012, at 10:06 PM, Jeremy Lakeman wrote:
>>>> 
>>>>> I propose that the BSSID is generated as a hash of the SSID. This way
>>>>> each mesh network will have a unique, but static BSSID without needing
>>>>> the user to know it.
>>>>> 
>>>>> On Sat, May 12, 2012 at 3:33 AM, Hans-Christoph Steiner
>>>>> <hans at guardianproject.info> wrote:
>>>>>> 
>>>>>> The trickiest thing for the user of the OlsrMeshTether app remains the ad-hoc network associating.  If a bunch of phones are starting up at the same time, they can easily start associating with themselves in clusters.  Then there is multiple meshes that can't talk to each other.
>>>>>> 
>>>>>> It seems a simple solution to this is to just hard-code the BSSID for Commotion in general as a default, then allow people to change this if they really want to.  I propose using CC:CC:CC:CC:CC:CC as the static BSSID.
>>>>>> 
>>>>>> Is there any reason why we wouldn't want to use a static BSSID as the default?
>>>>>> 
>>>>>> .hc
>>>>>> _______________________________________________
>>>>>> Commotion-dev mailing list
>>>>>> Commotion-dev at lists.chambana.net
>>>>>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>>>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> Commotion-dev mailing list
>>> Commotion-dev at lists.chambana.net
>>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>>> 
>> 
>> --
>> Josh King
>> 
>> "I am an Anarchist not because I believe Anarchism is the final goal,
>> but because there is no such thing as a final goal." -Rudolf Rocker
>> 
> 
> 
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> http://lists.chambana.net/mailman/listinfo/commotion-dev
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20120517/0f9f0fda/attachment.sig>


More information about the Commotion-dev mailing list