<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">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 class="im"><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 class="h5"><br>
--<br>
Olsr-users mailing list<br>
<a href="mailto:Olsr-users@lists.olsr.org">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>