[Commotion-dev] static BSSID?
L. Aaron Kaplan
aaron at lo-res.org
Thu May 17 20:23:20 UTC 2012
On May 17, 2012, at 10:12 PM, Hans-Christoph Steiner wrote:
>
> If you have multiple mesh nodes radiating on the same frequency in the same area, so that the radio waves overlap, is there ever a time with an OLSR mesh
> where it would be preferable to have those nodes on separate BSSIDs? That's the case I'm talking about.
>
Yes, you actually could think about that.
Why? Because you limit the number of neighbors this way. And then you get smaller OLSR packets.
But in general: if the density of nodes on the same frequencies is too high, then you are in trouble. No matter which protocol.
> For Ad-hoc networks, if your neighbor happens to be radiating on the same frequency, that doesn't mean you want to your ad-hoc network to merge with theirs.
Exactly!
> That would cause confusion with DHCP servers, different IP ranges and devices on the network, different internet connections, etc.
>
ACK.
Ok, maybe I misunderstood you and was just nit-picking on one particular sentence.
> .hc
>
> On May 17, 2012, at 11:16 AM, L. Aaron Kaplan wrote:
>
>> 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.
>>
>> 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.
>>>
>>> .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/7df09032/attachment-0001.sig>
More information about the Commotion-dev
mailing list