[Olsr-users] OLSR 0.6.8 on OpenWrt with ipv6 and kernel 3.18.x

[Ferry Huberts]

On 23/03/15 08:18, Russell Senior wrote:
>
> Ferry> I am skiing now so I didn't read the full thread.  Might be
> Ferry> because of mc local loopback. In pud I made that an option
> Ferry> because of testing. Might be that some socket sets it up.
>
> Ferry> Ping me next week to have me read the thread :-)
>
> ping!

blast, should have said 'in 2 weeks'
will try to catch up soon

>
> --
> Ferry HubertsOn 16 Mar 2015 09:17, Henning Rogge <(spam-protected)> wrote:
>>
>> On Mon, Mar 16, 2015 at 9:10 AM, Russell Senior
>> <(spam-protected)> wrote:
>>> ...
>>> Looking at strace output, it appeared that the datagram that
>>> was recvfrom'd on both sockets was identical, as if it was read on both
>>> of them, select told it to read from both.  E.g.:
>>>
>>> [...]
>>> 2522  01:01:23.560773 gettimeofday({1426492883, 560970}, NULL) = 0
>>> 2522  01:01:23.561072 select(11, [7 8 9 10], NULL, NULL, {0, 0}) = 2 (in[9 10], left {0, 0})
>>> 2522  01:01:23.561412 gettimeofday({1426492883, 561565}, NULL) = 0
>>> 2522  01:01:23.561675 recvfrom(9, "\4\234]\262\4,\0008\1\4p\351b\2\301\0\0\0\0\0\0\0\1\376\1\357}\1\4p\351b\2\301\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\0\0\0\0\0\0\0\0\3,\0(\1\4p\351b\2\301\0\0\0\0\
>>> 2522  01:01:23.563525 recvfrom(9, 0x80875b0, 1504, 0, 0xbfcd7020,0xbfcd6fd8) = -1 EAGAIN (Resource temporarily unavailable)
>>> 2522  01:01:23.563826 recvfrom(10, "\4\234]\262\4,\0008\1\4p\351b\2\301\0\0\0\0\0\0\0\1\376\1\357}\1\4p\351b\2\301\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\0\0\0\0\0\0\0\0\3,\0(\1\4p\351b\2\301\0\0\0\0
>>> 2522  01:01:23.565356 time([1426492883]) = 1426492883
>>> 2522  01:01:23.565594 open("/etc/TZ", O_RDONLY) = 12
>>> 2522  01:01:23.565843 read(12, "PST8PDT\n", 68) = 8
>>> 2522  01:01:23.566075 close(12)         = 0
>>> 2522  01:01:23.566363 send(6, "<30>Mar 16 01:01:23 olsrd[2522]: detected duplicate packet with seqnr 0x5db2 from 2001:470:e962::407 on ptp (1180 Bytes)\0", 121, MSG_NOSIGNAL) = 121
>>
>>
>>> 2522  01:01:22.373999 send(6, "<30>Mar 16 01:01:22 olsrd[2522]: Adding interface ptp\n\0", 55, MSG_NOSIGNAL) = 55
>>> 2522  01:01:22.374918 socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 9
>>> 2522  01:01:22.375210 setsockopt(9, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0
>>> 2522  01:01:22.375481 setsockopt(9, SOL_SOCKET, SO_RCVBUF, [130048], 4) = 0
>>> 2522  01:01:22.375741 setsockopt(9, SOL_SOCKET, SO_REUSEADDR, [130048], 4) = 0
>>> 2522  01:01:22.376095 setsockopt(9, SOL_SOCKET, SO_BINDTODEVICE, [7369840], 4) = 0
>>> 2522  01:01:22.376352 bind(9, {sa_family=AF_INET6, sin6_port=htons(698), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=8}, 28) = 0
>>> 2522  01:01:22.376646 fcntl64(9, F_GETFL) = 0x2 (flags O_RDWR)
>>> 2522  01:01:22.377021 fcntl64(9, F_SETFL, O_RDWR|O_NONBLOCK) = 0
>>> 2522  01:01:22.377260 socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 10
>>> 2522  01:01:22.377534 setsockopt(10, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0
>>> 2522  01:01:22.377797 setsockopt(10, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
>>> 2522  01:01:22.378050 setsockopt(10, SOL_SOCKET, SO_BINDTODEVICE, [7369840], 4) = 0
>>> 2522  01:01:22.378296 bind(10, {sa_family=AF_INET6, sin6_port=htons(698), inet_pton(AF_INET6, "2001:470:e962::1181", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=8}, 28) = 0
>>> 2522  01:01:22.378590 fcntl64(10, F_GETFL) = 0x2 (flags O_RDWR)
>>> 2522  01:01:22.378813 fcntl64(10, F_SETFL, O_RDWR|O_NONBLOCK) = 0
>>> 2522  01:01:22.379046 setsockopt(9, SOL_IPV6, IPV6_ADD_MEMBERSHIP, "\377\2\0\0\0\0\0\0\0\0\0\0\0\0\0m\10\0\0\0", 20) = 0
>>> 2522  01:01:22.379333 setsockopt(9, SOL_IPV6, IPV6_MULTICAST_IF, [8], 4) = 0
>>> 2522  01:01:22.379586 setsockopt(10, SOL_IPV6, IPV6_ADD_MEMBERSHIP, "\377\2\0\0\0\0\0\0\0\0\0\0\0\0\0m\10\0\0\0", 20) = 0
>>> 2522  01:01:22.379857 setsockopt(10, SOL_IPV6, IPV6_MULTICAST_IF, [8], 4) = 0
>>> 2522  01:01:22.380124 setsockopt(10, SOL_SOCKET, SO_PRIORITY, [192], 4) = 0
>>> 2522  01:01:22.380382 setsockopt(10, SOL_IPV6, 0x43 /* IPV6_??? */, [192], 4) = 0
>>
>> 9 and 10 should be a socket pair, one for sending the multicast
>> message with a specific source-IP and one for sending them. I have no
>> real clue why you are receiving them from both addresses. Still, the
>> whole IPv6-multicast handling in olsrd was always a mess. *sigh*
>>
>> Ferry, any idea what is going on here?
>>
>> Henning

-- 
Ferry Huberts