[OLSR-users] Help with OLSR Mesh

Sven-Ola Tuecke (spam-protected)
Sat Jun 10 12:07:05 CEST 2006


Hey,

adhoc has nothing special. The BSSID stuff is _below_ the ethernet layer 
just as in managed mode. Only difference: The BSSID used in managed mode 
tends to be the copied MAC from the master iface. That's a standard, not a 
law by nature. For a normal iptables installation, there should be no 
problem using "iptables -I INPUT -m mac --mac-source 00:11:22:33:44:55 -j 
DROP".

P.S. IMO it not very useful to check meshing in a lab. One of the lessons 
I've learned in the last 2 years: never believe those academic crowd. Some 
of them really don't know what they are talking about, because they hate 
climbing ladders heading for the roofs. Climatic conditions inside NS2 are 
really different from real world ;-)

P.P.S: To simulate a bit more accurate, write a new ipt plugin. Grab 
/dev/urandom and mark some random packets (e.g. 20%-80%). Marked packets -> 
/dev/null.

HTH Sven-Ola

""Joe Bush"" <(spam-protected)> schrieb im Newsbeitrag 
news:(spam-protected)
>I just tested using mac filtering and it failed miserably. I am told
> now that adhoc doesn't allow mac filtering because communication is
> doesn't using the comming bssid that all the nodes share.
>
> Strangely, I read a paper where someone had a testbed they claimed
> used mac filtering in order to force multiple hops in the mesh.
>
> Joe
>
> On 6/9/06, Jaime Vargas <(spam-protected)> wrote:
>> Ong,
>>
>>   if you are using cards with a txpower setting you could use
>> the lowest dBm value possible. This way you could see some
>> mesh routing happening thru intermediate nodes..
>>
>> -- Jaime
>>
>> On Jun 9, 2006, at 11:10 AM, Joe Bush wrote:
>>
>> > You could use MAC filtering in order to allow communication only with
>> > certain nodes.
>> >
>> > Joe
>> >
>> >
>> > On 6/9/06, Ong Chin Kiat <(spam-protected)> wrote:
>> >> Hi all,
>> >>
>> >> I'm currently attempting to set up an OLSR-based mesh network
>> >> using 4 Linux
>> >> boxes. The OLSRd daemon is running fine, and the topology table as
>> >> well as
>> >> the routing table looks ok. However, due to the fact that the 4
>> >> nodes are
>> >> next to each other (in a lab environment), the transfer of data is
>> >> through
>> >> direct connection, which actually negates the effects of OLSR on the
>> >> performance of the mesh.
>> >>
>> >> Hence, I would like to know if it is possible to force the data to go
>> >> through another node before reaching the destination. If so, how
>> >> can I do
>> >> it? I have tried to add one more wireless interface on the
>> >> destination, such
>> >> that ath0 has address 10.0.0.4 with route metric 30 and ath1 has
>> >> address
>> >> 10.0.0.5 with route metric 10. But then the problem here is that
>> >> if I send
>> >> data out to one IP address, then I am totally bypassing the route
>> >> metric
>> >> system.
>> >>
>> >> Suggestions?
>> >>
>> >> Thanks,
>> >> Ong Chin Kiat
>> >>
>> >> _______________________________________________
>> >> olsr-users mailing list
>> >> (spam-protected)
>> >> https://www.olsr.org/mailman/listinfo/olsr-users
>> >>
>> >>
>> >>
>> >
>> > _______________________________________________
>> > olsr-users mailing list
>> > (spam-protected)
>> > https://www.olsr.org/mailman/listinfo/olsr-users
>> >
>>
>> --
>> Jaime E. Vargas
>> Why Wire, Inc.
>> 601 Birch St. SW
>> Vienna, VA 22180
>> T. 703-766-0939
>>
>>
>>
>> _______________________________________________
>> olsr-users mailing list
>> (spam-protected)
>> https://www.olsr.org/mailman/listinfo/olsr-users
>>
>
> _______________________________________________
> olsr-users mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-users 





More information about the Olsr-users mailing list