[Olsr-users] olsrd 0.6.6.1 (and earlier) ipv6 problems

[Henning Rogge]

On 03/26/2014 07:41 PM, Russell Senior wrote:
> Anybody get a chance to look at the strace?  I see a:

strace and packet dumps are much too lowlevel to directly hunt problems
like this. Thats why Saverios question about txtinfo good, because it
gives you a much more high-level view on what is going on.

>   17798 02:13:19.127877 write(1, "TC: del edge entry 2001:470:e962::407 > 2001:470:e962:1201::1, cost (0.553/1.000) 1.808\n", 88) = 88

Thats normal logging output of OLSRd... you should see the same by
adding a loglevel of 1 or 3 to your configuration without all the other
strace noise.

> followed a short time later by instances like this:
> 
>   17798 02:13:19.641377 write(1, "TC: del edge entry 2001:470:e962:1001::1 > 2001:470:e962::407, cost (1.000/1.000) 1.000\n", 88) = 88
>   17798 02:13:19.641420 write(1, "RIB: del prefix 2001:470:e962::1001/128 from 2001:470:e962:1001::1\n", 67) = 67
>   17798 02:13:19.641461 write(1, "RIB: del prefix 2001:470:e962:1001::/64 from 2001:470:e962:1001::1\n", 67) = 67
>   17798 02:13:19.641501 write(1, "RIB: del prefix 2001:470:e962:1001::1/128 from 2001:470:e962:1001::1\n", 69) = 69
>   17798 02:13:19.641543 write(1, "TC: add entry 2001:470:e962:1001::1\n", 36) = 36
>   17798 02:13:19.641575 write(1, "RIB: add prefix 2001:470:e962:1001::1/128 from 2001:470:e962:1001::1\n", 69) = 69
>   17798 02:13:19.641614 write(1, "RIB: add prefix 2001:470:e962:1001::/64 from 2001:470:e962:1001::1\n", 67) = 67
>   17798 02:13:19.641657 write(1, "Inserting alias 2001:470:e962::1001 for ", 40) = 40
>   17798 02:13:19.641687 write(1, "2001:470:e962:1001::1\n", 22) = 22
>   17798 02:13:19.641717 write(1, "RIB: add prefix 2001:470:e962::1001/128 from 2001:470:e962:1001::1\n", 67) = 67
>   17798 02:13:19.641758 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbf9c3928) = -1 ENOTTY (Inappropriate ioctl for device)
>   17798 02:13:19.641782 gettimeofday({1395738799, 641789}, NULL) = 0
> 
> which coincide with the routing table collapse.  Around the time the
> routing table begins recovering, I see instances like this:
> 
>   17798 02:13:39.289467 write(1, "Processing TC from 2001:470:e962:1281::1, seq 0x3dd3\n", 53) = 53
>   17798 02:13:39.289503 write(1, "TC:   found neighbor tc_entry 2001:470:e962::407\n", 49) = 49
>   17798 02:13:39.289536 write(1, "TC:   found inverse edge for 2001:470:e962:1281::1\n", 51) = 51
>   17798 02:13:39.289572 write(1, "TC: add edge entry 2001:470:e962:1281::1 > 2001:470:e962::407, cost (0.000/0.000) INFINITE\n", 91) = 91
>   17798 02:13:39.289622 write(1, "Inserting alias 2001:470:e962::1281 for ", 40) = 40
>   17798 02:13:39.289652 write(1, "2001:470:e962:1281::1\n", 22) = 22
>   17798 02:13:39.289681 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbf9c3928) = -1 ENOTTY (Inappropriate ioctl for device)
>   17798 02:13:39.289705 gettimeofday({1395738819, 289712}, NULL) = 0
> 
> Is that illuminating at all?
> 
> Oh, and I'm seeing the persistent routing table collapse again.  It is
> cured by turning off the ipv6 version of olsrd on a particular node.

Okay, lets get back to the high-level view.

To interpret the events you described we need a list of nodes, with
their interface IPs and the connectivity between them. I am also a bit
worried about your usage of bridges connected to mesh interfaces.
Normally you should no bridge any interface that OLSR uses for meshing.
Mixing routing (L3) and bridging (L2) can go wrong in very creative ways.

Txtinfo output would be good (especially /route) would be good to see...
before the problem, during the problem and after the recovery.

It would also help if you can reduce the number of nodes while still
replicating the problem to a minimum.

Henning Rogge


-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:(spam-protected) http://www.fkie.fraunhofer.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6169 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20140327/bc3df8a6/attachment.bin>