<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">My problem turns out to be with olsrd+ serval problem. I tested by turning off all firewalls, then eventually by turning off serval signing. <div><br></div><div><div>OLSR in debug shows up the following on the central node C. </div><div><br></div><div><div style="margin: 0px; font-size: 11px; font-family: Menlo;">[MDP] Match for 192.168.168.34</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;">[MDP] Timestamp slack: 743296215</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;">[MDP] Timestamp scew detected!!</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;">[MDP] Timestamp mismatch in packet from 192.168.1.34!</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;">[MDP] Rejecting packet from 192.168.1.34</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;">[MDP] Checking packet for challenge response message...</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;"><br></div><div style="margin: 0px; font-size: 11px; font-family: Menlo;"><br></div><div style="margin: 0px; font-size: 11px; font-family: Menlo;"><div style="margin: 0px;">Then I installed NTP server on Node F (1.34) and ntp client on node C. When clocks on the two hosts are within seconds, I get</div><div style="margin: 0px;"><div style="margin: 0px;">[MDP] Checking packet for challenge response message...</div><div style="margin: 0px;">[MDP] Rejecting packet from 192.168.1.34</div><div style="margin: 0px;">[MDP] Checking packet for challenge response message...</div><div style="margin: 0px;"><br></div><div style="margin: 0px;">or </div><div style="margin: 0px;"><div style="margin: 0px;"><div style="margin: 0px;">[MDP] Match for 192.168.1.34</div><div style="margin: 0px;">[MDP] Message from non-validated host!</div><div style="margin: 0px;">[MDP] Timestamp mismatch in packet from 192.168.1.34!</div><div style="margin: 0px;">[MDP] Rejecting packet from 192.168.1.34</div><div style="margin: 0px;">[MDP] Adding signature for packet size 20</div><div style="margin: 0px;">[MDP] timestamp: 1404190197</div></div></div><div style="margin: 0px;"><br></div><div style="margin: 0px;">MD5 for the serval keychain libraries confirms that they are identical. I've been able to get asymmetrical routes (as mailed yesterday) using this shared key. </div><div style="margin: 0px;"><br></div><div style="margin: 0px;"><br></div></div><div style="margin: 0px;"><br></div><div style="margin: 0px;"><div style="margin: 0px;">Host F, 1.34 is a buffalo I built from master. </div><div style="margin: 0px;"><div style="margin: 0px;"> *** <a href="http://olsr.org">olsr.org</a> - pre-0.6.6.2-git_779bc7a-hash_4a8e5a728989421b6ecb7308a6e41f6c *** </div><div style="margin: 0px;"><br></div><div style="margin: 0px;">Host C, 1.33 * node<span style="font-family: Helvetica; font-size: 12px;"> E are ubiquiti M, using the shipping 1.1rc2 image. </span></div><div style="margin: 0px;"> *** <a href="http://olsr.org">olsr.org</a> - 0.6.5.4-git_8b2236e-hash_3667acb4ad7e32204039db1f6b9bc660 </div><div style="margin: 0px;"><br></div><div>Host E is the same as F, but without NTP - clock skew causes F to drop all packets from E, but sometimes they work?</div><div><br></div><div><br></div><div>And as final proof, disabling serval signing makes everything work. </div><div><br></div><div>Sigh. </div><div><br></div></div></div></div><div style="margin: 0px; font-size: 11px; font-family: Menlo;"><br></div><div style="margin: 0px; font-size: 11px; font-family: Menlo;">Is there a good way to bootstrap a serval signed mesh without an Internet gateway? </div><div style="margin: 0px; font-size: 11px; font-family: Menlo;"><br></div><div style="margin: 0px; font-size: 11px; font-family: Menlo;"><br></div><div><div>On Jun 30, 2014, at 7:09 AM, Dan Staples <<a href="mailto:danstaples@opentechinstitute.org">danstaples@opentechinstitute.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">+1 to what Chris said. That seems to be exactly the problem we saw<br>recently, with the firewall fix detailed in that Github issue.<br><br>Dan<br><br>On 06/30/2014 06:22 AM, Chris Ritzo wrote:<br><blockquote type="cite">This sounds like the same issue we encountered in a recent mesh<br>deployment at AMC. It may be a firewall zone bug specific to meshing<br>over ethernet. This may help diagnose/fix:<br><br><a href="https://github.com/opentechinstitute/commotion-router/issues/128">https://github.com/opentechinstitute/commotion-router/issues/128</a><br><br><br><br>On Mon 30 Jun 2014 04:23:56 AM EDT, miles wrote:<br><blockquote type="cite"><br><br>I'm having problems with the following mesh<br>Subnet -> wifi -> Device F ->ethernet link -> Device C -> wifi link -> Device A or Device E<br><br>C gets updates from F, A and E. Route table looks good & it can connect to Subnet and the other routers.<span class="Apple-converted-space"> </span><br><br>F only gets routes for C.<span class="Apple-converted-space"> </span><br>A gets routes only for E.<span class="Apple-converted-space"> </span><br>E gets routes only for A<br><br>all hosts are using the same serval keyring & signing key. All are rc1.1r2.<span class="Apple-converted-space"> </span><br>Each node has a wired ether interface and a mesh interface. The wired interface is unplugged except for nodes F & C.<span class="Apple-converted-space"> </span><br><br>I suspect that part of my problem may be with HNA.<span class="Apple-converted-space"> </span><br><a href="https://commotionwireless.net/docs/cck/installing-configuring/common-configuration/">https://commotionwireless.net/docs/cck/installing-configuring/common-configuration/</a> suggests disabling HNA for both devices in "Two wireless devices meshed over an ethernet connection". This seems counter intuitive. Don't I still want to announce both AP subnets?<span class="Apple-converted-space"> </span><br><br>Any suggestions where I should look for problems?<span class="Apple-converted-space"> </span><br><br><br>_______________________________________________<br>Commotion-dev mailing list<br><a href="mailto:Commotion-dev@lists.chambana.net">Commotion-dev@lists.chambana.net</a><br>https://lists.chambana.net/mailman/listinfo/commotion-dev<br></blockquote><br><br></blockquote><br>--<span class="Apple-converted-space"> </span><br>Dan Staples<br><br>Open Technology Institute<br><a href="https://commotionwireless.net/">https://commotionwireless.net</a><br>OpenPGP key:<span class="Apple-converted-space"> </span><a href="http://disman.tl/pgp.asc">http://disman.tl/pgp.asc</a><br>Fingerprint: 2480 095D 4B16 436F 35AB 7305 F670 74ED BD86 43A9<br>_______________________________________________<br>Commotion-dev mailing list<br><a href="mailto:Commotion-dev@lists.chambana.net">Commotion-dev@lists.chambana.net</a><br><a href="https://lists.chambana.net/mailman/listinfo/commotion-dev">https://lists.chambana.net/mailman/listinfo/commotion-dev</a></div></blockquote></div><br></div></div></body></html>