Hello, Jeremy I think has answered the broadcast issue, so I will focus more on the entropy issue. On Thu, Oct 24, 2013 at 3:48 PM, Miles <myles@tenhand.com> wrote:

On Wednesday, October 23, 2013 9:18:36 PM UTC-7, Paul Gardner-Stephen wrote:

...

Howdy,

...

I think it is better that we harvest a nice lump of entropy from the

radios rather than install random data (that might give naughty people help reproducing your private keys). We could read RSSI levels from the UHF radio, hash it a couple of times, and feed some bits into the entropy pool. This would just require talking to the radio a bit, which isn't too hard.

Using the radio as a HWRNG is interesting. Wouldn't RSSI be easily predictable (and influenceable) by any observer with an SDR radio? At the very least you'd need to tune the radio to an unknown channel, bandwidth & hopping code first. Or use the difference between the two radios in a clever way. User space clock solutions like havaged or DakaRand seem easier.

I think clocks are good to use, also. For the radio RSSI, we could easily make an entropy gathering mode where the radio hops over quite a wide band, perhaps from about 870MHz ~ 1000MHz in a random pattern sampling ambient energy levels, i.e. without talking to a remote radio, just listening. Combine that with some clock input, and feeding the RSSI results into the forward channel selection to help further randomise the hopping sequence while sampling for RSSI, and we should be able to make a fairly robust entropy source. Thoughts? Paul.

...

...

...

I am not sure how easy it would be to detect the address conflicts when they occur (regardless of address range and size). It would probably require some careful thought and work to implement it

I agree that it is ugly in many ways, short of getting a doctoral student to work on the problem for a few years. Even then, we still need a solution until then. Let's keep thinking about it for a few days and see if either of us can come up with a good solution.

IP collisions could be an unintended accident or a deliberate DOS. In the case of DOS, doing nothing seems better than amplifying/feeding the energy monster.

Using the Mac -> IP conversion, we know that any accidental collision will share our last 3 MAC bytes. But the odds are very good they won't share bytes 2-3. RARP/ARP/RARP would be awesome if it didn't fail for hidden/distant/lossy nodes.

Nodes with IP address conflicts can still send and receive broadcast traffic. What is serval already broadcasting that we could use to look for trouble unicasting? Broadcast to nearest node's (serval?) echo service, unicast to them, if the response doesn't come back, re-Ip?

-- You received this message because you are subscribed to the Google Groups "Serval Project Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-developers+unsubscribe@googlegroups.com. To post to this group, send email to serval-project-developers@googlegroups.com. Visit this group at http://groups.google.com/group/serval-project-developers. For more options, visit https://groups.google.com/groups/opt_out.

-- You received this message because you are subscribed to the Google Groups "Serval Project Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-developers+unsubscribe@googlegroups.com. To post to this group, send email to serval-project-developers@googlegroups.com. Visit this group at http://groups.google.com/group/serval-project-developers. For more options, visit https://groups.google.com/groups/opt_out.