<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Very good -- on the edge of my seat to see what happens :)<br>
Thanks for the explanation. <br>
<br>
I've always enjoyed working with OLSR, we had a lot of success w/
ahdemo mode on an older MADWIFI setup that has been rock solid -- no
ad-hoc splits, just data w/ great throughput etc. Need to migrate
someday to some newer hardware and move to the latest OLSR -- maybe
next year.<br>
<br>
Henning Rogge wrote:
<blockquote
cite="mid:CAGnRvuqQyRpjZgosJMetc+_qZYq8L9vsCdcC_O8ddUX9MLm5sQ@mail.gmail.com"
type="cite">
<pre wrap="">On Mon, Jul 28, 2014 at 3:23 PM, Eric Malkowski <a class="moz-txt-link-rfc2396E" href="mailto:eric@bvwireless.net"><eric@bvwireless.net></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">It is interesting that the gateway node stops transmitting OLSR packets all
together.
In an older version (we're talking 0.5.6 I think) there was an old timer bug
where the system call times() return value goes negative and then the timers
wouldn't work anymore until you reboot. I find it interesting that this
problem happens and upon restarting OLSRd it still won't work and you have
to resort to reboot so uptime of the OS is zeroed. Does it seem to be
uptime related?
</pre>
</blockquote>
<pre wrap=""><!---->
We moved away from times() because of this bug to "gettimeofday()" and
added a special wrapper that fix time-zone jumping and stuff like
this.
If gettimeofday() returns an error, OLSR will immediately end with the
error message "OS clock is not working, have to shut down OLSR" and a
return code of 1. It cannot work without a clock.
(Olsrd2 use clock_gettime() (if available) to ask the OS for the
raw_monotinic or monotonic clock... but I would guess this could also
fail.)
So running it from the command line instead of forking into background
should reveal this.
On Mon, Jul 28, 2014 at 7:37 PM, Antonio Anselmi <a class="moz-txt-link-rfc2396E" href="mailto:tony.anselmi@gmail.com"><tony.anselmi@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Henning,
I think it's not a network error since the the adHoc beacons work (all node
are associated at layer2). I think that the Eric Malkowski reply in
mailing-list could be a good hint (olsrd timers go off so scheduler stops to
send packets).
</pre>
</blockquote>
<pre wrap=""><!---->
I have seen cases where the interface changed in a subtile way to that
every attempt to send a packet to the OLSR socket returned an error.
In both cases (time related and network related) you should see an
output in the debug log.
If possible please run the routing agent with debug level 1 and look
at the last lines.
Henning Rogge
</pre>
</blockquote>
<br>
</body>
</html>