Hi,<div><br></div><div>A few questions/suggestions.</div><div><br></div><div>1) I understand the difficulties with managing routes. It seems to me that a good engineering approach would be to define a range of IP addressed for which OLSR will be doing the routing. This method will give you an opportunity to have multiple routing algorithms managing different routes.</div>

<div><br></div><div>2) Does OLSR implementation cache routes within its own code? If not I guess, it really is an issue to have writing to the routing table fail because it could potentially impact the entire network as opposed to just the local host. If it does do caching, can we simply keep a bool indicating if the route update was performed correctly or not. Using this extra info, you could actually reapply the change upon other route update or in the main OLSR loop. This seems fairly os agnostic ...</div>

<div><br></div><div>If I enable a higher level of debugging, will I get the error codes for writing to the socket? I guess one potentially issue is that I have VMWare installed on my mac. It did add other interfaces, however, OLSR is configured to ignore them.</div>

<div><br></div><div>Thanks,</div><div>-- Octav<br><div><br><div class="gmail_quote">On Wed, Nov 10, 2010 at 9:30 AM, Mitar <span dir="ltr"><<a href="mailto:mmitar@gmail.com">mmitar@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 class="im">Hi!<br>
<br>
On Wed, Nov 10, 2010 at 5:54 PM, Markus Kittenberger<br>
<<a href="mailto:Markus.Kittenberger@gmx.at">Markus.Kittenberger@gmx.at</a>> wrote:<br>
</div><div class="im">> i just pointet out, that the os-specific parts of olsrd`s routing code (that<br>
> lives inside the olsr_ioctl_add_route() ), can not use any infrastructure of<br>
> the os-unspecific olsrd-core at the moment to try it later,.. (it can only<br>
> try again immediately, but not later)<br>
<br>
</div>I am not saying that it should be in os-unspecific part of the code.<br>
No, there is no need for that. It can be in os-specific part and just<br>
try again immediately.<br>
<div class="im"><br>
> but before thinking about this i would like to see a EAGAIN error,..<br>
<br>
</div>Yes, EAGAIN is not so often and it depends on current configuration of<br>
file descriptor. EINTR is much more often (common?) if you use<br>
signals.<br>
<div class="im"><br>
> especially as there are no ioctl functions involved!<br>
<br>
</div>But there is write function which at least in my page has:<br>
<br>
EAGAIN The file descriptor fd has been marked non-blocking<br>
(O_NONBLOCK) and the write would block.<br>
<br>
EINTR  The call was interrupted by a signal before any data was<br>
written; see signal(7).<br>
<br>
So, wrapping write calls to netlink socket in os-specific (Linux) part<br>
of code would not be so hard to add. But I agree, when there will be<br>
reason for that.<br>
<font color="#888888"><br>
<br>
Mitar<br>
</font></blockquote></div><br></div></div>