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

[Ferry Huberts]

I am skiing now so I didn't read the full thread.

Might be because of mc local loopback. In pud I made that an option because of testing. Might be that some socket sets it up.

Ping me next week to have me read the thread :-)

--
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