'-w' was only introduced in a recent version of iptables. It means
"Wait for the xtables lock", so it seems reasonable to proceed without
it for older versions.
Instead of ip/netmask. This should be functionally equivalent (for
now), and makes it easier to identify the rule as belonging to
weave. Unfortunatley we must still match the source with ip/netmask,
since we are in the POSTROUTING chain and source interface matches
aren't valid there.
See also issue #20.
which, as well as stopping&removing the weave container also clears
the UDP connection tracking for the weave port, without which UDP
connections to a quickly (<3min) re-started weave would fail.
Fixes#18
Issues with the previous scheme...
When we have just encountered an EMSGSIZE, the odds of encountering
another one straight away, when attemtping to send a verification
packet with the lower mtu, are slim, since for a new, lower mtu to be
set some packet must have made it further then the one that triggered
the icmp3.4 that gave rise to the EMSGSIZE, and we must have received
the resulting icmp3.4. All of which takes time.
Also, sending a bunch of udp packets in rapid succession is not a
great way to improve their chances of making it through to the other
peer, since they could easily all get dropped by a single congestion
event or other network glitch.
Now we send a single verification packet, wait for a short while, and
if we don't get a response then we send another one, wait for longer
period (2x), etc, until some upper bound is reached, at which point we
lower the pmtu and start the verification process again (same as
currently happens).
We are now also calling flush() to send the verification packet, just
as we do for ordinary packets. This makes for shorter code, consistent
error handling, and introduces a nice little recursion :)
rade