[Olsr-users] Olsr Multicast Streaming Question

[Teco Boot]

Op 5 jan 2011, om 11:31 heeft Erik Tromp het volgende geschreven:

> 
>>    destination: set to the "01:00:5e:" multicast address, 
>>      instead of all-ones.
> 
> For BMF, this may or may not be a good idea. BMF uses (local, layer 2)
> broadcast as underlying medium. Using "01:00:5e" as the first three bytes
> in the Ethernet destination address may incorrectly trigger multicast
> snooping/optimization algorithms of the layer 2 infrastructure equipment.

Hmm. This is about RFC1112 Level 1 hosts, that want to receive multicast, 
but do not join / leave hosts groups. And yes, BMF supports broadcast and
link local multicast. 
But still, RFC1122 section 6.4 applies also to Level 1 hosts. So they MUST
support the Ethernet multicast addresses.
RFC4541 L2 boxes do not introduce problems. 224.0.0.x is flooded.
So I prefer the compliant mode, using "01:00:5e" for IPv4 multicast
and all-ones for broadcast. Having a config flag would be OK.
 

>> - If BMF sends out with source addresses of captured frames,
>>   this is to be corrected. I think BMF uses tap tunnel (instead 
>>   of tun). Using tun saves some bytes also.
> 
> BMF transparently encapsulates all packets. The receiver sees the originally
> sent packet,
> with the original source address.
> 
> BMF uses tun, not tap. See the function 'CreateLocalEtherTunTap' in
> NetworkInterfaces.c

OK. This eliminates transfer of Ethernet addresses over the tunnel.


Thanks, Teco

> 
> Best regards,
> Erik
> 
> 
> -----Oorspronkelijk bericht-----
> Van: (spam-protected)
> [mailto:(spam-protected)] Namens Teco Boot
> Verzonden: woensdag 5 januari 2011 9:13
> Aan: NaTo ClubSilom
> CC: (spam-protected)
> Onderwerp: Re: [Olsr-users] Olsr Multicast Streaming Question
> 
> Couple of remarks:
> - You use 224.0.0.1 multicast address. This is for link-local. 
>   BMF supports forwarding such packets, but IMHO it is better
>   to use a more appropriate address (such as 239.x.x.x)
> - I assume you use WLAN cards, in ad hoc mode. Then,
>   NodeC and NodeD could receive packets from NodeA every now
>   and then. Did you check this? (inspect olsr links)
> - On BMF and other multicast plugins: more cleanup is needed 
>   on Ethernet address handling. The p2pd plugin has code for 
>   setting correct addresses:
>     source: the address of sending interface
>     destination: set to the "01:00:5e:" multicast address, 
>       instead of all-ones. (But I just saw the version in 
>       stable repository has a bug, to be corrected soon).
>       IP Broadcast packets should keep using all-ones.
> - If BMF sends out with source addresses of captured frames,
>   this is to be corrected. I think BMF uses tap tunnel (instead 
>   of tun). Using tun saves some bytes also.
> 
> Regards, Teco.
> 
> 
> Op 4 jan 2011, om 17:53 heeft NaTo ClubSilom het volgende geschreven:
> 
>> Hello I'have a senior project in comscience major . The topic is about
> performance measurements in olsr multicast network.
>> 
>> My Topology Have 4Node : NodeA : 192.168.1.1/24,NodeB : 
>> 192.168.1.2/24,NodeC :192.168.1.3,NodeD :192.168.1.4
>> 
>> all Node is run on Ubuntu 10.04 and olsrd 0.6.1 with bmf 1.7.0
>> 
>> Topology looklike
>>                                                    -   NodeC
>>                                           -         
>>                                    -   
>> NodeA --------- NodeB 
>>                                    - 
>>                                           -
>>                                                    -   NodeD
>> 
>> I use VLC for streaming multicast 224.0.0.1 from NodeA To NodeC and 
>> NodeD via NodeB . I don't understand why stream packet arrived to NodeC
> And NodeD have a source macaddress is NodeA not NodeB and port is vlc port
> not bmf port.
>> 
>> Sorry I'm not good in english
>> 
>> Regards
>> NaTo
>> --
>> Olsr-users mailing list
>> (spam-protected)
>> http://lists.olsr.org/mailman/listinfo/olsr-users
> 
> 
> -- 
> Olsr-users mailing list
> (spam-protected)
> http://lists.olsr.org/mailman/listinfo/olsr-users
>