<div dir="ltr"><div>(oops, accidentally replied off-list. Reposting)<br><div class="gmail_quote"><span dir="ltr"><br>Hello</span><br><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span>On Sat, Jan 3, 2015 at 6:58 AM, Andrei Borzenkov <span dir="ltr"><<a href="mailto:arvidjaar@gmail.com" target="_blank">arvidjaar@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span> </span>So if I understand it correctly you want<br> <br> - configure one interface<br> - start some program that establishes what you call "uplink". I presume<br> it results in one more interface appearing?<br> - configure new "uplink" interface<br> <br> Am I right? Could you explain in some more details your setup?</blockquote><div><br></div></span><div>You are right. The interface wlan0 is configured, and provides internet connectivity to a machine having a br0 bridge.<br><br></div><div>br0 is bridging ap0 (a local access point) and vpn0 (uplink) so that clients connected on this access point access the vpn transparently.<br><br></div><div>br0 should be configured automatically, along with the others - it should just not block wait-online from saying the system is online<br></div><div><br></div><div>I saw an interesting discussion of the problem on <a href="http://www.spinics.net/lists/netdev/msg172204.html" target="_blank">http://www.spinics.net/lists/netdev/msg172204.html</a><br><br></div><div>I agree with the OP conclusion <a href="http://www.spinics.net/lists/netdev/msg174826.html" target="_blank">http://www.spinics.net/lists/netdev/msg174826.html</a><br>"The situation of a bridge is quite different from a physical ethernet interface. The physical interface is usually connected to a switch and is thus immediately up, even if no systems other than the switch are online. In the case of a bridge on a virtualization host used to connect virtual machines, the bridge only goes up after the first VM was started. In the IPv6 SLAAC case, the host tries start its radvd on the bridge well before the first VM comes up, the radvd barfs since the interface is not up, does not come up, and the VMs are without network. In this case, it is needed to force the bridge into an UP state earlier so that radvd can start."</div><div><br></div><div>My situation is indeed similar to setting up a bridge for virtual machines only. Like lo, such bridges should be ignored by systemd-networkd-wait-online under some conditions.<br><br></div><div>What about another option in networkd-wait-online-link.c to pass an "ignore" parameter, along with a list of interfaces names, so that link_relevant does: something like:<br><br> if (l->flags & IFF_LOOPBACK)<br> return false;<br><br> if (<span>STR_IN_SET(l->ifname, arg_ignore)) {</span><br> return false;<br></div><span><div><br></div><div>At the moment, my dirty workaround is to have br0 hardcoded in manager_all_configured from src/network/networkd-wait-online-manager.c:<br><br>if (!link_relevant(l) || STR_IN_SET(l->ifname, "br0")) {<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span></span>Yes, systemd-networkd-online will wait for all known links to become<br> ready.<span><br></span></blockquote><div><br></div></span><div>It should have an option to ignore some, as not all links are relevant. It would be the opposite of -i, which specifies which are important (ex: here it can be either wlan0 or eth0 depending on the situation, while br0 is always to be ignored)<br></div><div><br>$ ip address show<br>(...)<br>8: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default <br><br> I have to find a way to make br0 appear "ready".<br></div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span> </span>This sounds like broken approach. If I follow your configuration<br> correctly, br0 is *the* interface that provides your network<br> connectivity so wait-online should wait until it is up and running.<br></blockquote><div><br></div></span><div>Not exactly - wlan0 or eth0 provide network connectivity to the machine.<br></div><div>br0 (ap0 +vpn0) are for other computers<br> <br></div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> What is missing here is the ability to express dependency on individual<br> interfaces. Alternatively support for callouts would help (start<br> external helper to configure uplink as soon as physical interface is<br> ready).</blockquote><div><br></div></span><div>Indeed<br><br></div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think it was discussed and for now it is intentional - you need to<br> restart networkd to pick configuration changes but networkd will not<br> wipe clean existing configuration.<br><div><div></div></div></blockquote><div><br></div></span><div>Too bad. That would also be an interesting option. At the moment there is no way to automatically clean what networkd has done.<br></div><span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It is up to client to renew address. May be networkd could optionally<br> set very short lease time to force renewal.<br> </blockquote></span></div><br></div><div class="gmail_extra">That would be a great addition. It would fix the problem.<br><br>Alternatively, some control allowing to stop the DHCP server on this interface would help.<br></div></div> </div><br>In case the suggested patch to systemd-networkd-wait-online isn't accepted, I investigated an alternative : adding a dummy0 to br0 as suggested by the link above.<br><br>It is indeed better : br0 then has a carrier.<br><br>However in networkctl it is still considered unconfigured:<br><br>$ networkctl:<br>IDX LINK TYPE OPERATIONAL SETUP<br>(...)<br> 4 br0 ether routable configuring<br><br>I tested that futher by adding a br1 with a similar setup, only without any DHCP<br><br>[Match]<br>Name=br1<br><br>[Network]<br>Address=<a href="http://192.168.200.224/28" target="_blank">192.168.200.224/28</a><br><br>$ networkctl:<br>IDX LINK TYPE OPERATIONAL SETUP<br>(...)<br> 5 br1 ether no-carrier configured<br><br>This seems very similar to the bug reported before on <a href="https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg22414.html" target="_blank">https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg22414.html</a><br><br>Basically, the DHCP commands prevent considering the bridge online. This would be logical if there was only a DHCP section, but if someone also configured a fixed IP, it should inhibit this wrong behaviour.<br><br>I traced the problem to link_client_handler in src/network/networkd-link.c :<br>if (link_dhcp4_enabled(link) && !link->dhcp4_configured) return;<br><br>This can't just be commented out, because it's necessary for interfaces using only DHCP.<br>Maybe it could become conditionnal to the interface not having an ip address? That could be cleaner that adding the oppositive of the -i option.<br><br>Also, for interfaces added to a bridge but without ip (ex: ap0 from hostap), listing the service as "degraded" seems wrong.<br><br>$ networkctl:<br>IDX LINK TYPE OPERATIONAL SETUP<br>(...)<br> 5 ap0 wlan degraded configured<br><br></div>Being part of the bridge is their normal setup. They can't have an IP address.<br><div><br>PS: I've noticed this message in my logs, without much more details:<br>systemd-resolved : Assertion 'n > 0' failed at src/resolve/resolved-dns-answer.c:28, function dns_answer_new(). Aborting<br><br>It does not seem like a known problem, and I don't see why it would happen. It looks like there were many DNS replies on the same link<br><br>Charles<br><br></div></div>