[Olsr-dev] Idea for small OLSR improvement
Sat Apr 24 19:25:18 CEST 2010
maybe (in addtion to pinging) verify if olsrd packets from the other side
arrive regulary (ideally log all seqnr of them (tcpdump|grep[|sed] is
enough), so u can independently calculate lq based on this,...)?
imho it `s quite likely that if pings work, olsrd braocast packets will work
if so, there would be non influence on olsr/routing from any layer <=2
(which means you problem is probably inside olsr and/or its config)
On Sat, Apr 24, 2010 at 5:28 PM, Mitar <(spam-protected)> wrote:
> On Sat, Apr 24, 2010 at 5:14 PM, Sven-Ola Tücke <(spam-protected)> wrote:
> > madwifi. Absolutely. Check you kernel log for "stuck beacon" messages. I
> > it's the case. Have you tried the openwrt/kamikaze patchset together with
> > "adhocmode with HAL in master?" That's the nosbeacon flag when you do
> > "wlanconfig create ath0..."
> Stuck beacons are there but I have not noticed that it would
> correlate. I will do a little bit more thorough tests/analysis. Also
> pings (every second) worked without problems in both directions while
> OLSR was dropping the route.
> But yes, I also have it as a main suspect. Will investigate more.
> But I also read here:
> that this workaround has impact on Broadcom hardware:
> It has been observed that this little TSF deviants confused devices
> with Broadcom chipsets, such as the Linksys WRT54GL: They were still
> working but they stopped sending beacons.
> Is this true? Is there no other less hacky solution? Is there any work
> being done to fix this in HAL?
> This is why I am not really enthusiast about using this approach.
> Olsr-dev mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Olsr-dev