<br><br><div class="gmail_quote">On Wed, Aug 17, 2011 at 9:26 PM, Andrea Di Pasquale <span dir="ltr"><<a href="mailto:spikey.it@gmail.com">spikey.it@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div>Whenever olsrd establishes a route, such as:</div></div></blockquote><div><br></div><div>hmm one last try to clarify things: (-;</div><div><br></div><div>1. olsrd does not deal with arp resolution or even mac adresses,..</div>
<div>infact it never does anything, which will "directly" trigger any arp action</div><div><br></div><div>(except its optional arp_refresh plugin, wihich i would simply not use together with arpOn)</div><div><br>
</div><div>but yes an olsrd nodes/meshes can suffer from arp-spoofing.<br>(like any device, which uses arp protocol)</div><div><br></div><div>but i still see no reason why it should be an olsrd plugin,.. (cause of 1.)</div>
<div>(an till now, you never presented a reason for this,..)</div><div><br></div><div>it should be enough to simply run arpOn on any mesh node,..</div><div><br></div><div>as i assume no interaction of arpon and olsrd is needed.</div>
<div>arpon "just" have to make sure that the mac adresses in the local arptable are correct. (same as it will do on a node which does not even run olsrd)</div><div><br></div><div>Markus</div></div>