<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Wed, 12 Aug 2009 16:12:33 +0100
From   : philb@... (Phil Blundell)
Subject: Econet <> Ethernet

On Wed, 2009-08-12 at 15:30 +0100, Rob wrote:
> On 12/08/2009, michael.firth@... <michael.firth@...> wrote:
> > You might also want some other form of persistent ID in these messages, so
> > that more than one gateway can sit behind the same NAT device (and hence IP
> > address) - I'm not completely sure why you'd need this, but it seems
> > sensible to make the protocol capable of supporting it.
> 
> It might be easier to make it a configureable port number,
> particularly for incoming connections that have to be forwarded by a
> cheap home router which can generally only cope with one onward
> destination per port ..

Yeah, that's probably a better plan.  Otherwise you end up needing a
separate demux, which would be a bit silly.

> What about some sort of identification code or password that needs to
> be quoted on a registration in order for it to connect?  That would
> stop just anybody connecting into the virtual econet.  md5(password) ?

Good idea.  I'm slightly nervous about fitting an md5 routine into the
200-or-so bytes of spare flash space that I have at my disposal, so we
might need to compromise slightly on that.  How about (X)TEA?

Or, personally I would be happy enough just sending the password in
cleartext: this isn't really intended to be a high security system, and
you can always tunnel it inside IPsec or something if you're worried.  

> Also, what happens if gateway A and gateway B both connect to gateway
> C, and the hosts behind A want to talk to hosts behind B - does
> traffic have to go via C, or should there be a way for C to inform A
> and B about each other?

I think traffic would just go via C in that case.  I'd envisaged this
network being basically a hub system where there would be a central
switching host to which all the others connected, rather than a pile of
ad-hoc point to point links.  Doing anything much beyond that starts to
require "real" routing protocols and, again, rather more intelligence
than I have space for in my AVR microcontroller :-}

p.
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>