[Commotion-dev] meshing over ethernet

[miles]

My problem turns out to be with  olsrd+ serval problem. I tested by turning off all firewalls, then eventually by turning off serval signing. 

OLSR in debug shows up  the following on the central node C.  

[MDP] Match for 192.168.168.34
[MDP] Timestamp slack: 743296215
[MDP] Timestamp scew detected!!
[MDP] Timestamp mismatch in packet from 192.168.1.34!
[MDP] Rejecting packet from 192.168.1.34
[MDP] Checking packet for challenge response message...


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
[MDP] Checking packet for challenge response message...
[MDP] Rejecting packet from 192.168.1.34
[MDP] Checking packet for challenge response message...

or 
[MDP] Match for 192.168.1.34
[MDP] Message from non-validated host!
[MDP] Timestamp mismatch in packet from 192.168.1.34!
[MDP] Rejecting packet from 192.168.1.34
[MDP] Adding signature for packet size 20
[MDP] timestamp: 1404190197

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. 



Host F, 1.34 is a buffalo I built from master. 
 *** olsr.org -  pre-0.6.6.2-git_779bc7a-hash_4a8e5a728989421b6ecb7308a6e41f6c *** 

Host C, 1.33 * node E are ubiquiti M, using the shipping 1.1rc2 image. 
 *** olsr.org -  0.6.5.4-git_8b2236e-hash_3667acb4ad7e32204039db1f6b9bc660 

Host E  is the same as F, but without NTP - clock skew causes F to drop all packets  from E, but sometimes they work?


And as final proof, disabling serval signing makes everything work. 

Sigh. 


Is there a good way to bootstrap a serval signed mesh without an Internet gateway? 


On Jun 30, 2014, at 7:09 AM, Dan Staples <danstaples at opentechinstitute.org> wrote:

> +1 to what Chris said. That seems to be exactly the problem we saw
> recently, with the firewall fix detailed in that Github issue.
> 
> Dan
> 
> On 06/30/2014 06:22 AM, Chris Ritzo wrote:
>> This sounds like the same issue we encountered in a recent mesh
>> deployment at AMC. It may be a firewall zone bug specific to meshing
>> over ethernet. This may help diagnose/fix:
>> 
>> https://github.com/opentechinstitute/commotion-router/issues/128
>> 
>> 
>> 
>> On Mon 30 Jun 2014 04:23:56 AM EDT, miles wrote:
>>> 
>>> 
>>> I'm having problems with the following mesh
>>> Subnet -> wifi -> Device F ->ethernet link -> Device C -> wifi link -> Device A or Device E
>>> 
>>> C gets updates from F, A and E.   Route table looks good & it can connect to Subnet and the other routers. 
>>> 
>>> F  only gets routes for C. 
>>> A gets routes only for  E. 
>>> E gets routes only for A
>>> 
>>> all hosts are using the same serval keyring & signing key.  All are rc1.1r2. 
>>> Each node has a wired ether interface and a mesh interface.  The wired interface is unplugged except for nodes F & C. 
>>> 
>>> I suspect that part of my problem may be with HNA. 
>>> https://commotionwireless.net/docs/cck/installing-configuring/common-configuration/ 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? 
>>> 
>>> Any suggestions where I should look for problems? 
>>> 
>>> 
>>> _______________________________________________
>>> Commotion-dev mailing list
>>> Commotion-dev at lists.chambana.net
>>> https://lists.chambana.net/mailman/listinfo/commotion-dev
>> 
>> 
> 
> -- 
> Dan Staples
> 
> Open Technology Institute
> https://commotionwireless.net
> OpenPGP key: http://disman.tl/pgp.asc
> Fingerprint: 2480 095D 4B16 436F 35AB 7305 F670 74ED BD86 43A9
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> https://lists.chambana.net/mailman/listinfo/commotion-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20140630/720f3612/attachment.html>