[Commotion-dev] meshing over ethernet

[Dan Staples]

Serval signed routes will work without a gateway/NTP. However, it will
definitely take up to 5 minutes for the timestamps to converge. They
*will* converge though, even if the starting clocks on the nodes are
days or months apart. Give it a few minutes and see if it starts working
again.

Also, did things work with serval signing off and the original firewall
rules on? I'm still curious if the firewall rules are adding an
additional barrier.

dan

On 07/01/2014 01:03 AM, miles wrote:
> 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 <http://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 <http://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
> <mailto: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
>>>> <mailto:Commotion-dev at lists.chambana.net>
>>>> https://lists.chambana.net/mailman/listinfo/commotion-dev
>>>
>>>
>>
>> -- 
>> Dan Staples
>>
>> Open Technology Institute
>> https://commotionwireless.net <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 <mailto: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