[OLSR-users] Running two insances of olsr

Cyrille Chepelov (spam-protected)
Tue Jun 22 16:26:11 CEST 2004

Le Tue, Jun 22, 2004, à 04:06:10PM -0800, Andreas Tønnesen a écrit:

> >, v4, eth0
> >2001:7a8:29d4:0:2a0:24ff:fea6:57a0/64, v6, eth0
> >2001:7a8:29d4::1/64, v6, eth0
> >## fe80::2a0:24ff:fea6:57a0/64, v6, eth0 ##skipped: link-local
> >##, v4, lo ## skipped: loopback
> >## ::1/128, v6, lo ## skipped: loopback
> >## fe80::2e0:98ff:feb5:18df/64, v6, eth1 ##skipped: link-local
> >	# (yes, my eth1 is not used right now: just got around to
> >	# checking that it's a prism54 and that's all I had the time to
> >	# do)
> >
> >Now, for each of the specific three addresses above, create a listening
> >socket. Have exactly one ipv6 per physical interface join the multicast
> >group and send broadcast messages? Not sure. Initially we might just
> >leave duplicate traffic, maybe we'd better have one ipv6 address per 
> >network perform multicast duties. Or maybe the RFC covers this already.
> >As you now know for each socket, whether it's supposed to receive v4 or
> >v6 traffic, you can run the correct packet parser.

> I am [NOT]following you here. Wouldn't this require binding muliple	
> sockets to UDP/698? If one is to create one socket for every address on
> the interface, you'll have to bind all of them to the same port for them
> to receive the traffic... Or am I missunderstanding you here?

Indeed, you need to bind multiple sockets to udp/698, which is fine as long as 
no two sockets are bound to the same (address,proto,port) tuple. This is

> Anyways, you still need the socket to device binding for the outgoing
> traffic to be able to control on whay interface traffic is sent.

You should be able to pick one socket per interface as the "outbound" socket, 
and use it to send the (broad|multi)casts. struct socket_entry probably
needs another field, "relevant interface". Walk the list of struct socket_entry until you found a socket that is the right ip dialect on the right interface, 
and broadcast away!

	-- Cyrille


More information about the Olsr-users mailing list