olsr-users - a mailinglist where users can post questions and discuss olsrd related issues.

Henning Rogge | 1 Mar 2012 08:01

Re: Network address associated with fingerprint of the node's public key?

On 02/28/2012 07:59 PM, Wojciech Zabolotny wrote:
>> Maybe a distributed address distribution could help. Or just switch to IPv6
>> and choose your IP based on the MAC address of your WLAN card (or just with
>> a random suffix).
>>
> Unfortunately this can be spoofed as well.

I was just thinking about an address selection algorithm that can run 
without a central instance.

> OK. So probably it should include generation of symmetric keys for exchange of
> packets between each pair of nodes. The challenge-response mechanism should
> be used only when establishing the communication between those nodes.
> (As you describe it below.)
You also need an authentication system for the mesh-wide flooding of 
messages of the routing protocol. Thats something which cannot be done 
easily with symmetric crypto.

> In the simplest version, the IP could be just the appropriate number
> of bytes from the fingerprint of the key. So the asymmetric key is generated
 > first, then the fingerprint is calculted and IP is obtained from it. Of
 > course in this case the IP is somehow randow, however in my experiments
 > (up to ca. 20 node) the olsr protocol could handle fully random IP 
addresses
 > (well, I don't know how it would scale up for a network consisting of 
e.g.
 > 200 nodes covering a small town.)
Okay.

OLSR don't do better or worse with randomized IPs. It doesn't care. ^^

(Continue reading)

headers

Wojciech Zabolotny | 1 Mar 2012 23:00

Re: Network address associated with fingerprint of the node's public key?

On Thu, Mar 1, 2012 at 8:01 AM, Henning Rogge
<henning.rogge <at> fkie.fraunhofer.de> wrote:
>
> I will try to summarize your proposal...
>
> A) every node generates a public/private key pair
> B) every node selects its mesh IP based on the Hash of the public key
> C) when a node wants to send unicast traffic to another node the first time,
> it requests the public key from the target node, then use standard security
> protocols like IPsec/OpenVPN to establish a secure end-2-end channel.
>
Generally yes, however I'd propose additionally, that the messages
used to maintain the mesh network (calculation of the routing tables)
should be also cryptographically protected (using the node's private key -
when broadcasted or using encrypted channels, when sent as unicast messages).
Nodes detected as spoofing ones should be blacklisted, and the information
they provide should not be used by other nodes to update their routing tables.
-- 
Wojtek

--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users

headers

Henning Rogge | 2 Mar 2012 08:10

Re: Network address associated with fingerprint of the node's public key?

On 03/01/2012 11:00 PM, Wojciech Zabolotny wrote:
> On Thu, Mar 1, 2012 at 8:01 AM, Henning Rogge
> <henning.rogge <at> fkie.fraunhofer.de>  wrote:
>>
>> I will try to summarize your proposal...
>>
>> A) every node generates a public/private key pair
>> B) every node selects its mesh IP based on the Hash of the public key
>> C) when a node wants to send unicast traffic to another node the first time,
>> it requests the public key from the target node, then use standard security
>> protocols like IPsec/OpenVPN to establish a secure end-2-end channel.
>>
> Generally yes, however I'd propose additionally, that the messages
> used to maintain the mesh network (calculation of the routing tables)
> should be also cryptographically protected (using the node's private key -
> when broadcasted or using encrypted channels, when sent as unicast messages).
> Nodes detected as spoofing ones should be blacklisted, and the information
> they provide should not be used by other nodes to update their routing tables.

This will increase the size of the routing messages quite a bit (and the 
CPU consumtion), because you will have to put a signature on every 
generated routing message and check the signature of every incoming 
signature.

But if you have enough network and CPU capacity, it might work. 
Especially with the IPv6 solution, because the address space should be 
large enough to prevent bruteforce attacks.

Henning Rogge

(Continue reading)

headers

Ben West | 2 Mar 2012 21:20

Re: OLSR txtinfo plugin not working on OpenWRT Backfire 10.03.1?

Thanks Markus.

I confirm that this works now to get output from the txtinfo plugin (assuming plugin configured for port 2006):

echo "/all" | nc localhost 2006

On Wed, Feb 29, 2012 at 5:41 PM, Markus Kittenberger <Markus.Kittenberger <at> gmx.at> wrote:

try "/all" instead just "all"

Markus

On Wed, Feb 29, 2012 at 11:40 PM, Ben West <me <at> benwest.name> wrote:

Hi All,

I recently upgraded all my UBNT M5 units to from Backfire r25206 to Backfire 10.03.1, which comes with these OLSRD pkgs:

olsrd - 0.6.1-3

olsrd-mod-arprefresh - 0.6.1-3

olsrd-mod-dyn-gw - 0.6.1-3

olsrd-mod-httpinfo - 0.6.1-3

olsrd-mod-nameservice - 0.6.1-3

olsrd-mod-secure - 0.6.1-3

olsrd-mod-txtinfo - 0.6.1-3

olsrd-mod-watchdog - 0.6.1-3

The OLSRD txt info plugin worked with the version included with Backfire 25206, but now trying to connect to port 2006 either fails (connection refused), or nothing is returned.

root <at> nsm5-c:~# wget -qO- http://127.0.0.1:2006/

root <at> nsm5-c:~# <nothing>

root <at> bm-b:~# echo "all" | nc localhost 2006

HTTP/1.0 200 OK

Content-type: text/plain

<nothing>

This is the relevant clause from my olsrd.conf, which is unchanged from when the txtinfo plugin worked under Backfire r25206.

# Don't remove olsrd_txtinfo from this file

# as this plugin is used by the Webinterface

# to display the OLSR Info

LoadPlugin "olsrd_txtinfo.so.0.1"

{

PlParam "port" "2006"

PlParam "Accept" "127.0.0.1"

}

Is this a known problem?

--
Ben West

me <at> benwest.name

--
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users

Ben West

me <at> benwest.name

--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users

headers

Ben West | 3 Mar 2012 01:11

Recommendation for maintaining accurate local times on nodes?

I'm running OLSR v0.6.1 packaged with OpenWRT 10.03.1 on a collection of Ubiquiti M5 access points (Rocket, Bullet, Nanostation, Nano Loco).

All radios have /etc/init.d/ntpdate service enabled on boot to sync local time to a remote NTP server, although this only succeeds on non-gateway nodes if OLSRd (also enabled on boot) finds and sets a default route before ntpdate times out.

In the case where ntpdate does time out before setting a node's local time, I've noticed letting that node operate as-is in the mesh can cause other nodes to lose their default route. Presumably from the non-sync'ed node sending out HNA's with bad timestamps? Is this expected OLSR behavior?

Besides simply letting ntpdate run on all nodes as an hourly or daily cron job, would anyone have other recommendations on keeping all nodes' local time synced?

Ben West

me <at> benwest.name

--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users

headers

Bruce Ford | 3 Mar 2012 08:50

Re: Recommendation for maintaining accurate local times on nodes?

Perhaps use the ntp client included in the OpenWRT BusyBox rather than ntpdate or install the full NTP client. See http://wiki.openwrt.org/doc/howto/ntp.client

Bruce Ford

On Sat, Mar 3, 2012 at 10:11 AM, Ben West <me <at> benwest.name> wrote:

I'm running OLSR v0.6.1 packaged with OpenWRT 10.03.1 on a collection of Ubiquiti M5 access points (Rocket, Bullet, Nanostation, Nano Loco).

All radios have /etc/init.d/ntpdate service enabled on boot to sync local time to a remote NTP server, although this only succeeds on non-gateway nodes if OLSRd (also enabled on boot) finds and sets a default route before ntpdate times out.

In the case where ntpdate does time out before setting a node's local time, I've noticed letting that node operate as-is in the mesh can cause other nodes to lose their default route. Presumably from the non-sync'ed node sending out HNA's with bad timestamps? Is this expected OLSR behavior?

Besides simply letting ntpdate run on all nodes as an hourly or daily cron job, would anyone have other recommendations on keeping all nodes' local time synced?

--
Ben West

me <at> benwest.name

--
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users

--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users

headers

Ben West | 3 Mar 2012 08:57

Re: Recommendation for maintaining accurate local times on nodes?

Hi Bruce,

Thanks for the response. I do have the full ntpdate client installed on these nodes. The problem seems to be that ntpdate only (by default) syncs on power-up, so any nodes that don't quickly get a default route set by OLSRd have ntpdate time out.

A simple solution seems like it would be to run ntpdate periodically, though I'm not sure if running as often as hourly may interfere with the timestamps on the HNAs (e.g. introduce excessive jitter). The onboard clocks on the UBNT radios are not that precise; I've seen a 1 minute or so drift develop over a day.

On Sat, Mar 3, 2012 at 1:50 AM, Bruce Ford <fordbr <at> gmail.com> wrote:

Perhaps use the ntp client included in the OpenWRT BusyBox rather than ntpdate or install the full NTP client. See http://wiki.openwrt.org/doc/howto/ntp.client

Bruce Ford

On Sat, Mar 3, 2012 at 10:11 AM, Ben West <me <at> benwest.name> wrote:

I'm running OLSR v0.6.1 packaged with OpenWRT 10.03.1 on a collection of Ubiquiti M5 access points (Rocket, Bullet, Nanostation, Nano Loco).

All radios have /etc/init.d/ntpdate service enabled on boot to sync local time to a remote NTP server, although this only succeeds on non-gateway nodes if OLSRd (also enabled on boot) finds and sets a default route before ntpdate times out.

In the case where ntpdate does time out before setting a node's local time, I've noticed letting that node operate as-is in the mesh can cause other nodes to lose their default route. Presumably from the non-sync'ed node sending out HNA's with bad timestamps? Is this expected OLSR behavior?

Besides simply letting ntpdate run on all nodes as an hourly or daily cron job, would anyone have other recommendations on keeping all nodes' local time synced?

--
Ben West

me <at> benwest.name

--
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users

--
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users

Ben West

me <at> benwest.name

--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users

headers

Teco Boot | 3 Mar 2012 13:09

Re: Recommendation for maintaining accurate local times on nodes?

I stopped using ntpdate, ntp does a far better job.

I don't see a relation to olsd.

Teco

Op 3 mrt. 2012, om 08:57 heeft Ben West het volgende geschreven:

Hi Bruce,

Thanks for the response. I do have the full ntpdate client installed on these nodes. The problem seems to be that ntpdate only (by default) syncs on power-up, so any nodes that don't quickly get a default route set by OLSRd have ntpdate time out.

A simple solution seems like it would be to run ntpdate periodically, though I'm not sure if running as often as hourly may interfere with the timestamps on the HNAs (e.g. introduce excessive jitter). The onboard clocks on the UBNT radios are not that precise; I've seen a 1 minute or so drift develop over a day.

On Sat, Mar 3, 2012 at 1:50 AM, Bruce Ford <fordbr <at> gmail.com> wrote:
Perhaps use the ntp client included in the OpenWRT BusyBox rather than ntpdate or install the full NTP client. See http://wiki.openwrt.org/doc/howto/ntp.client

Bruce Ford

On Sat, Mar 3, 2012 at 10:11 AM, Ben West <me <at> benwest.name> wrote:

I'm running OLSR v0.6.1 packaged with OpenWRT 10.03.1 on a collection of Ubiquiti M5 access points (Rocket, Bullet, Nanostation, Nano Loco).

All radios have /etc/init.d/ntpdate service enabled on boot to sync local time to a remote NTP server, although this only succeeds on non-gateway nodes if OLSRd (also enabled on boot) finds and sets a default route before ntpdate times out.

In the case where ntpdate does time out before setting a node's local time, I've noticed letting that node operate as-is in the mesh can cause other nodes to lose their default route. Presumably from the non-sync'ed node sending out HNA's with bad timestamps? Is this expected OLSR behavior?

Besides simply letting ntpdate run on all nodes as an hourly or daily cron job, would anyone have other recommendations on keeping all nodes' local time synced?

--
Ben West

me <at> benwest.name

--
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users

--
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users

--
Ben West

me <at> benwest.name

--
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users

--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users

headers

Markus Kittenberger | 3 Mar 2012 20:40

Re: Recommendation for maintaining accurate local times on nodes?

olsr does not care if the time on a node is correct, synced or whatever.

Markus

On Sat, Mar 3, 2012 at 1:11 AM, Ben West <me <at> benwest.name> wrote:

I'm running OLSR v0.6.1 packaged with OpenWRT 10.03.1 on a collection of Ubiquiti M5 access points (Rocket, Bullet, Nanostation, Nano Loco).

All radios have /etc/init.d/ntpdate service enabled on boot to sync local time to a remote NTP server, although this only succeeds on non-gateway nodes if OLSRd (also enabled on boot) finds and sets a default route before ntpdate times out.

In the case where ntpdate does time out before setting a node's local time, I've noticed letting that node operate as-is in the mesh can cause other nodes to lose their default route. Presumably from the non-sync'ed node sending out HNA's with bad timestamps? Is this expected OLSR behavior?

Besides simply letting ntpdate run on all nodes as an hourly or daily cron job, would anyone have other recommendations on keeping all nodes' local time synced?

--
Ben West

me <at> benwest.name

--
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users

--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users

headers

Henning Rogge | 3 Mar 2012 20:44

Re: Recommendation for maintaining accurate local times on nodes?

But ntp and ntpdate care about a route to the server. ;)

Henning

On Sat, Mar 3, 2012 at 20:40, Markus Kittenberger
<Markus.Kittenberger <at> gmx.at> wrote:
> olsr does not care if the time on a node is correct, synced or whatever.
>
> Markus
>
> On Sat, Mar 3, 2012 at 1:11 AM, Ben West <me <at> benwest.name> wrote:
>>
>> I'm running OLSR v0.6.1 packaged with OpenWRT 10.03.1 on a collection of
>> Ubiquiti M5 access points (Rocket, Bullet, Nanostation, Nano Loco).
>>
>> All radios have /etc/init.d/ntpdate service enabled on boot to sync local
>> time to a remote NTP server, although this only succeeds on non-gateway
>> nodes if OLSRd (also enabled on boot) finds and sets a default route before
>> ntpdate times out.
>>
>> In the case where ntpdate does time out before setting a node's local
>> time, I've noticed letting that node operate as-is in the mesh can cause
>> other nodes to lose their default route.  Presumably from the non-sync'ed
>> node sending out HNA's with bad timestamps?  Is this expected OLSR behavior?
>>
>> Besides simply letting ntpdate run on all nodes as an hourly or daily cron
>> job, would anyone have other recommendations on keeping all nodes' local
>> time synced?
>>
>> --
>> Ben West
>> me <at> benwest.name
>>
>>
>> --
>> Olsr-users mailing list
>> Olsr-users <at> lists.olsr.org
>> https://lists.olsr.org/mailman/listinfo/olsr-users
>
>
>
> --
> Olsr-users mailing list
> Olsr-users <at> lists.olsr.org
> https://lists.olsr.org/mailman/listinfo/olsr-users

-- 
"Wo kämen wir hin, wenn alle sagten, wo kämem wir hin, und niemand
ginge, um einmal zu schauen, wohin man käme, wenn man ginge." (Kurt
Marti)

--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-users

Mon	Tue	Wed	Thu	Fri	Sat	Sun

			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31

41	May 2013
32	April 2013
19	March 2013
52	February 2013
12	January 2013
62	December 2012
37	November 2012
23	October 2012
45	September 2012
31	August 2012
25	July 2012
17	June 2012
17	May 2012
7	April 2012
35	March 2012
67	February 2012
23	January 2012
16	November 2011
56	October 2011
10	September 2011
63	August 2011
9	July 2011
45	June 2011
101	May 2011
75	April 2011
98	March 2011
21	February 2011
93	January 2011
44	December 2010
67	November 2010
61	October 2010
87	September 2010
22	August 2010
49	July 2010
51	June 2010
43	May 2010
17	April 2010
40	March 2010
25	February 2010
107	January 2010
63	December 2009
58	November 2009
39	October 2009
63	September 2009
38	August 2009
18	July 2009
35	June 2009
43	May 2009
86	April 2009
27	March 2009
56	February 2009
141	January 2009
56	December 2008
51	November 2008
57	October 2008
126	September 2008
126	August 2008
53	July 2008
82	June 2008
88	May 2008
7	April 2008
45	March 2008
47	February 2008
24	January 2008
26	December 2007
82	November 2007
27	October 2007
17	September 2007
21	August 2007
23	July 2007
15	June 2007
39	May 2007
47	April 2007
21	March 2007
67	February 2007
65	January 2007
21	December 2006
15	November 2006
23	October 2006
23	September 2006
15	August 2006
62	July 2006
75	June 2006
41	May 2006
57	April 2006
78	March 2006
85	February 2006
28	January 2006
28	December 2005
48	November 2005
28	October 2005
3	September 2005
76	August 2005
80	July 2005
104	June 2005
67	May 2005
188	April 2005
54	March 2005
132	February 2005
93	January 2005
81	December 2004
58	November 2004
72	October 2004
25	September 2004