[Commotion-dev] static BSSID?

Wed May 30 02:34:03 UTC 2012

Hi Sean,

I talked with Hans about this last week. Looks great, I think it will 
be a workable approach. I'll work on adding this to the next release of 
CommotionWRT, so we can test it out. Thanks!

On Fri 18 May 2012 05:04:42 PM EDT, Sean McIntyre wrote:
> Hey folks,
>
> Talked about this with Hans today. We came up with the following algorithm:
>
> BSSID = MD4(ESSID)[0:4] ++ channel 2-byte integer
>
> This is read in English as: "The six byte BSSID is the first four
> bytes of the MD4 hash of ESSID concatenated with the lowest two bytes
> of the channel."
>
> The rationale for this is that MD4 is uniformly distributed, and the
> first four bytes of MD4 are presumably uniformly distributed. (Should
> be distributed enough.) Then add on the bytes of the channel so that
> same ESSIDs don't collide. MD4 was an arbitrary function choice, and
> security is not an issue. :)
>
> I found a public domain implementation of MD4
> <http://openwall.info/wiki/people/solar/software/public-domain-source-code/md4>
> and made a simple get_bssid() function the same as the above algorithm
> (attached).
>
> Signature for get_bssid:
>
> get_bssid(char *essid, unsigned int channel, unsigned char *bssid) //
> (result goes in bssid)
>
> Not sure how to add this in, so hope one of you goes ahead and does
> that, or let me know how I can be of further service.
>
> Sean
>
> On Thu, May 17, 2012 at 4:23 PM, L. Aaron Kaplan <aaron at lo-res.org> wrote:
>>
>> 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
>>>>>
>>>>
>>>
>>
>>
>> _______________________________________________
>> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20120529/47d0b2aa/attachment.sig>