<div>afair just specify an unicast adress (the ip address of the neighbour) for Ipv4Broadcast on both sides, and it should be unicast traffic<br></div><div><br></div><div>bust maybe its still a broadcast, using an adress that looks like an unicast adress</div>
<div><br></div><div>(so better look at the ethernet header with tcpdump to be sure,.. (you should see the mac of your neighbour, an no multicast ethernet adress))</div><div><br></div><div>Markus</div><div><br></div><div>p.s. did u enable packet aggregation (or multicast optimization) on your osbridges, if so, turn it off!</div>
<div><br></div><br><div class="gmail_quote">On Thu, Feb 17, 2011 at 5:52 PM, Michael Rack <span dir="ltr"><<a href="mailto:michael.rack@rsm-freilassing.de">michael.rack@rsm-freilassing.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#FFFFFF" text="#000000">
Dear Markus and list,<br>
<br>
is there a change to get OLSR working UNICAST and not MULTICAST in
Layer 2?<br>
<br>
My Problem is not solved, my OSBRIDGE is routing MULTICAST
differently then UNICAST. OSBridge does not ACK Multicast Packets,
so that when the link becomes full, Multicast-Traffic (LAYER2) is
not reach the destination.<br>
<br>
The Setup is P2P, so UNICAST makes sense.<br>
<br>
How to get OLSR to send HELLO-Messages and all others as UNICAST?<div class="im"><br>
<br>
<pre cols="72">Liebe Grüße aus Freilassing,
Michael Rack
RSM Freilassing
--
RSM Freilassing Tel.: +49 8654 607110
Nocksteinstr. 13 Fax.: +49 8654 670438
D-83395 Freilassing <a href="http://www.rsm-freilassing.de" target="_blank">www.rsm-freilassing.de</a> </pre> <br></div><div><div class="h5">
On 23.12.2010 23:14, Markus Kittenberger wrote:
<blockquote type="cite"><br>
<br>
<div class="gmail_quote">On Thu, Dec 23, 2010 at 9:16 PM, Michael
Rack <span dir="ltr"><<a href="mailto:michael.rack@rsm-freilassing.de" target="_blank">michael.rack@rsm-freilassing.de</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> OLSR packets are sent over multicast. In IEEE 802.11,
unicast and<br>
> multicast packets use different link-layer protocols,
and it's fairly<br>
> usual to see much higher loss rates for multicast than
for unicast<br>
> packets.<br>
</div>
OLSR packets are set via broadcast, not multicast ;)<br>
multicast is a routed subnet via IGMP in range 224.0.0.0 -
239.255.255.255.<br>
</blockquote>
<div>routet or not, or which iprange, makes no difference at
layers < 3</div>
<div><br>
</div>
<div>regarding ethernet layer 2 any mac adress having the last
bit of the first byte set to 1 is a multicast,..</div>
<div>this includes broadcasts FF:FF:FF:FF:FF:FF or various types
of multicasts,..</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Broadcasts
should not be dropped anyway.<br>
</blockquote>
<div>having higher loss rate, does not imply the packets are
actively dropped,..</div>
<div> </div>
<div>i think what juliusz meant was that multicasts (including
broadcasts) are not acked or retransmitted in most IEEE 802.11
modes (e.g. WDS links are an exception)</div>
<div>thats why multicasts are usually easier lost than
unicasts,..</div>
<div><br>
</div>
<div>but osbridges are definetely not "always" IEEE 802.11
conform,..</div>
<div>(i think you mentioned that this link is done with
osbridges,..)</div>
<div><br>
</div>
<div>(to compensate this expectable higher loss rates)
broadcasts are usually sent with another (usually lower)
bitrate:<br>
the multicastrate<br>
</div>
<div><br>
</div>
<div>which is afair "unconfigureable" on osbridges,..</div>
<div>(but osbridge have a setting called "Multicast
Optimization", which imho is better turned off *G,or at least
try if changing it dos have effects on your problem,..)</div>
<div><br>
</div>
<div>but osbridges are definetely not "always" IEEE 802.11
conform,..</div>
<div><br>
e.g. when used in ptp-bridge mode, they do somewhat wdslike
things (but not exactly wds)</div>
<div>(but they will handle broadcasts like unicast in this mode
afair,.. (i.e the ack anr retransmit))</div>
<div><br>
</div>
<div>btw. i had once an rb411(bridge mode)-osbridge(ptp-client)
link having (sometimes) unbelieveable high olsr packet loss
(about 90%, while the link itself was doing fine), imho not
explainable by lack of retransmits alone.</div>
<div><br>
</div>
<div>i temporary fixed this by tunneling the traffic through
this link (which transformed all broadcasts to unicasts)<br>
(and later i replaced the osbridge against a routerboard,..)</div>
<div><br>
</div>
<div>
another approach would be to configure olsrd to use unicasts
instead of broadcasts *G (i.e. ip4broadcast=neighbor_ip on
both sides) (of course this only makes sense on a ptp link!!)</div>
<div><br>
</div>
<div>but when using 2 osbridges i never had such problems (but i
don`t use them since years ago for many other reasons,..)</div>
<div><br>
</div>
<div>Markus</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div><br>
--<br>
Olsr-users mailing list<br>
<a href="mailto:Olsr-users@lists.olsr.org" target="_blank">Olsr-users@lists.olsr.org</a><br>
<a href="http://lists.olsr.org/mailman/listinfo/olsr-users" target="_blank">http://lists.olsr.org/mailman/listinfo/olsr-users</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</div></div></div>
</blockquote></div><br>