Add multicast trace receiver to attic/. Another run of multicast trace reveals fairly nice behavior. It looks like the traffic jams are the fault of ARP, which results from a gaggle of hosts trying to send ping replies. ARP caching will help with that quite a bit.

2 files changed, 29 insertions, 0 deletions

diff --git a/attic/README.txt b/attic/README.txt
new file mode 100644
index 00000000..65cd9e91
--- /dev/null
+++ b/attic/README.txt
@@ -0,0 +1,2 @@
+This directory is for old code that isn't used but we don't want to lose
+track of, and for anything else random like debug scripts.
diff --git a/attic/multicast-trace-receiver.rb b/attic/multicast-trace-receiver.rb
new file mode 100755
index 00000000..74593859
--- /dev/null
+++ b/attic/multicast-trace-receiver.rb
@@ -0,0 +1,27 @@
+#!/usr/bin/ruby
+
+#
+# This can be used with the debug build option ZT_TRACE_MULTICAST to trace
+# a multicast cascade.
+#
+# Define ZT_TRACE_MULTICAST to the IP/port where this script will be listening.
+# The default port here is 6060, so an example would be to add:
+#
+# -DZT_TRACE_MULTICAST=\"10.0.0.1/6060\"
+#
+# ... to DEFS in the Makefile. Then build and run ZeroTier One on a testnet and
+# the box defined as the trace endpoint will get spammed with UDP packets
+# containing trace information for multicast propagation. This script then dumps
+# these trace packets to stdout. Look at the code in PacketDecoder.cpp to see
+# what this information entails.
+#
+
+require 'socket'
+
+s = UDPSocket.new
+s.bind('0.0.0.0',6060)
+
+loop {
+	m = s.recvfrom(4096)[0].chomp
+	puts m if m.length > 0
+}