[systemd-devel] miredo unit files

[Alexander E. Patrakov]

18.01.2011 03:54, Lennart Poettering wrote:
> On Fri, 07.01.11 22:26, Henry Gebhardt (hsggebhardt at googlemail.com) wrote:
>
>> Dear list members,
>>
>> I have been maintaining a systemd overlay for Gentoo.  Hence i was
>> contacted about how to get miredo running with systemd.  I herefore
>> forward you the email, in the hope to get some help as to the proper
>> solution.  Please find the problem description and proposed solution
>> below.
> Hmm, I am not sure how miredo works. Is the client something where you
> have to run one instance per network iface? Or do you have a global
> instance for all? If the latter, then why doesn't it watch the network
> interfaces on its own?

The client creates its own interface (called "teredo", but in fact it is 
just a tun interface). There cannot be more than one copy of the client, 
and it should only care about the IPv4 route to the teredo server (by 
default, teredo.ipv6.microsoft.com) which is often the default route.

>>> I don't know the way to tell systemd "don't start miredo until the
>>> system has the IP address specified in the BindAddress directive". So,
>>> systemd starts miredo as soon as it thinks it can. If the address
>>> specified in the BindAddress directive is missing at that point, miredo
>>> fails. The patch prevents the failure by setting the IP_FREEBIND socket
>>> option. So miredo doesn't exit right away, but instead fails to send the
>>> initial packet and goes into the "retry after 100 seconds" mode. The
>>> same happens without the patch if miredo is started before a route to
>>> the default server appears.
> Yes, systemd does not support
> activation-on-configuration-of-an-ip-address. My suggestion is to either
> patch the service in question to watch for network interfaces itself, or
> use IP_FREEBIND.

I patched miredo to use IP_FREEBIND. However, this still doesn't solve 
the problem, because of a 100-second delay between teredo interface 
configuration retries. The problem looks (oversimplified) like this:

miredo creates the socket and the teredo interface
miredo: "hey teredo server, which IPv6 address should I use?"
kernel drops packet, because there is no route (or, alternatively, DNS 
doesn't work yet and miredo fails to resolve the IPv4 address of the 
teredo server)
miredo waits a bit, gets upset
dhcpcd configures eth0, adds the default route
miredo is still upset
miredo waits 100 seconds
miredo: "hey teredo server, which IPv6 address should I use?"
kernel sends packet
teredo server replies

So it looks like miredo should reset its timeout when the routing table 
changes, and that I have to implement this myself. But I have no good 
tutorial on rtnetlink sockets.

-- 
Alexander E. Patrakov