[Olsr-users] OLSRv2 crashing with lan_import

[Henning Rogge]

On Sun, Jul 31, 2016 at 4:02 PM, Bastian Rosner <(spam-protected)> wrote:
> Hi,
>
> olsrd2 0.12.1 is crashing on current LEDE x86_64 when using lan_import
> on a table which is filled with IPv6-routes by olsrd.
>
> Kernel-message indicating crash:
> traps: olsrd2[2719] general protection ip:40aa5e sp:7ffc6d2e3f60 error:0
> in olsrd2[400000+5c000]
>
> Without "lan_import", OLSRv2 is running stable.
>
> My setup consists of three KVM LEDE instances, interconnected via
> GRETAP-tunnels. Two of three nodes are also running olsrd, on non-GRE
> interfaces, talking to our existing olsrdv1 mesh. olsrd is exporting
> IPv6 routes to table 100.
> The third node is only speaking OLSRv2 on two GRETAP-ifaces and is
> supposed to receive a bunch of attached_networks (originally OLSRv1)
> from the two other nodes.
> The whole exercise is to have a concept of migrating from OLSRv1 to
> OLSRv2 in an IPv6-only environment. Routes will obviously only be
> redistributed to OLSRv2, not vice-versa.
>
> /etc/config/olsrd2 on dual-stack nodes:
> # IPv6-only
> config olsrv2
>         list 'originator' '-0.0.0.0/0'
>         list 'originator' '-::1/128'
>         list 'originator' 'default_accept'
>
> # IPv6-only on two GRETAP-tunnels
> config interface
>         list 'ifname' 'l105'
>         list 'ifname' 'a36s'
>         option 'rx_bitrate' '1G'
>         option 'tx_bitrate' '1G'
>         list 'bindto' '-0.0.0.0/0'
>         list 'bindto' '-::1'
>         list 'bindto' 'default_accept'
>
> # import from table 100 (OLSRv1)
> config lan_import
>         option name '1'
>         list table '100'

Looks normal...


> Single-stack (OLSRv2 only) looks the same but lan_import section is
> disabled.
>
>
> On the OLSRv2-only node, seconds before olsrd2 on other node is
> crashing, logread shows this:
>
> Sun Jul 31 15:55:59 2016 daemon.warn OLSRd2[1359]: 0000: 0825f701
> ff07fd20 010bf707 50153200 00000000 000001ff 00edb900 11011001 .%.....
> ....P.2.................
> 0020: 92001001 62078002 08900102 b6ad0100 20010bf7 08310007 00000000
> 00000001 ....b........... ....1..........
> 0040: 00090710 0220010a 10010b01 0020010b f7083100 0a000000 00000000
> 01000907 ..... ....... ....1.............
> 0060: 1002f708 0a100131 01002001 0bf70831 000b0000 00000000 00010009
> 07100200 .......1.. ....1................
> 0080: 030a1001 0Sun Jul 31 15:55:59 2016 daemon.warn OLSRd2[1359]:
> WARN(rfc5444) e forwarding message: %s (%d) 1063: Error while parsing
> incoming packet from [fe80::8cb9:63ff:fe48:fae0]:269%gre-l105: Early end
> of packet (-2)
> Sun Jul 31 15:55:59 2016 daemon.warn OLSRd2[1359]: 0000: 0825f801
> ff080620 010bf707 50153200 00000000 000001ff 00edba00 11011001 .%.....
> ....P.2.................
> 0020: 92001001 62078002 08900102 b6ad0100 fd145eca 93530001 00000000
> 00000001 ....b.............^..S..........
> 0040: 00090710 0210000a 10010201 10fd1927 8b656700 00000000 00000000
> 00300009 ...............'.eg..........0..
> 0060: 07100210 000a1001 020100fd 19278b65 67000100 00000000 00000100
> 09071002 .............'.eg...............
> 0080: 10000a10 0

That looks like a packet corruption... the parser says the packet is too short.

Any special MTU value in your network?

> If there's anything else I can provide, please give me some hints on how
> to debug.

Any chance to use remote-gdb to get a full stacktrace?

If the bug is easy to replicate for you testing it with the new 0.12.2
would also be good (I will push a OpenWRT packet to my packet feed
tomorrow).

Henning