There were situations, such as deleting another connection as result
of it losing a tie-break, where lifecycle events of connections on the
local peer weren't logged.
Fixing that entails moving the logging closer to (i.e. right after)
the state change action. This in turn requires promotion of logging to
the Connection interface instead of it LocalConnection. Which in turn
requires a change from 'log' to 'Log', for consistency with other
interface methods.
Fixes#449.
Do not inject ICMP "fragmentation needed" for broadcast packets.
It's a contravention of RFC1122 and also breaks weave routing due to producing packets with broadcast addresses as the source.
Fixes#419.
* disable the default Vagrant shared folder, which we don't need
* install `bc` on the dev VM, since it's needed by the smoke tests
* expose the dev VM docker on TCP, for convenience
If forwarding of a broadcast frame resulted in a FrameTooBigError, we
would generate an ICMP "fragmentation needed" packet that contravened
RFC1122 on two counts: First, we should not produce a ICMP error
message in response to a broadcast/multicast packet. Secondly, we
should not produce an IP packet with a broadcast/multicast source IP
address. (It also gave an ethernet frame with a broadcast source MAC,
which probably contravenes some IEEE spec.)
So when RelayBroadcast gets a FrameTooBigError, it should just drop
the packet.
Futhermore, if we fail to relay a broadcast on one connection, that's
not a good reason to give up entirely - we can proceed to attempt to
relay on the other next hop connections. Errors other than
FrameTooBigError that propagated upwards were simply logged, so that
logging is moved down into RelayBroadcast.
- extract helper function
- use "lots and lots of MX records" instead of "lots of TXT records"
for testing large response
- calculate on the fly the number of records we need to generate a
large response
- don't hardcode "weave.works"
Improve the DNS server configuration mechanism. The new configuration
system includes the ability to specify a different domain name other
than ".weave.local".
In fact, remove the mention of the exported images being in the container
altogether. The images are in the host docker daemon, so it is easier to
export them again than to go fishing around with 'docker cp'.
Michael Bridgen