<div dir="ltr"><div class="gmail_extra">Hi Seth,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Sorry for the delayed responses on this thread (this is a side project of mine).</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 12, 2017 at 7:57 PM, Seth Arnold <span dir="ltr"><<a href="mailto:seth.arnold@canonical.com" target="_blank">seth.arnold@canonical.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"><div id="gmail-:38k" class="gmail-a3s gmail-aXjCH gmail-m15a1d700c49c61e5">Is this a manifestation of the bridge trying to do spanning tree protocol?<br>
Most of the walkthroughs I've read lately about bridged networking include<br>
commands to turn off STP before they start adding ports to the bridge.<br></div></blockquote><div><br></div><div>My present workaround is a /etc/network/interfaces file whose bridge looks something like this:</div><div><br></div><div><div>iface wan0 inet manual</div><div>    metric 5000</div><div>    bridge_ports enp1s0</div><div>    bridge_stp off</div><div>    bridge_waitport 0</div><div>    bridge_fd 0</div><div>    post-up run-one /root/ifmonitor enp1s0 &<br></div><div>    pre-down kill $(cat /run/ifmonitor.enp1s0) 2> /dev/null || true</div><div><br></div><div>So no, this particular issue isn't related to the spanning-tree configuration. (That part was unchanged when I was seeing the 5-minute timeouts.)</div></div><div><br></div><div>The 5-minute timeout was an issue with the interface set to 'auto' and the DHCP configuration present in /e/n/i. I had to replace that with the post-up script which manually monitored the interface and launched (or killed) the DHCP client to get the behavior I wanted (no 5-minute timeout of the WAN interface was disconnected or didn't respond to DHCP).</div></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Regards,</div><div class="gmail_extra">Mike</div></div>