Date   : Tue, 28 Jul 2009 12:15:53 +0100
From   : philb@... (Phil Blundell)
Subject: Econet <> Ethernet

On Tue, 2009-07-28 at 11:38 +0100, Rob wrote:
> But you don't need to use that because I also support an AUNMap file
> (copied off the A5000) to link net number to IP range, so to contact a
> given net.stn, it checks the overrides first, checks map for the
> network range, then assumes the last octet based on the station
> number.   (It then remembers all this for next time.)
> 
> Thus for me, 192.168.0.x is net 128,  192.168.12.x is net 132 and
> 192,168.13.x is net 133.

Yeah, that works well enough within a site where you can use
private-network addressing.  But for WAN routing across the Internet it
isn't quite sufficient because it would still require you to assign a
globally-routable IP to each station and that isn't likely to be
feasible for a lot of people.  (I'm not quite sure how RIPE would react
if you approached them requesting to be allocated a /24 network to use
with AUN, but I think the chances of success would be slim.)

In order to make it workable for routing between different sites, which
might only have a single globally-routable IP address each, you'd need
to add some kind of encapsulation or tunnelling layer on top of the AUN
protocol.  The easiest way to do that would be RFC2003 IP-in-IP.

> AUN seems to rely on IP routing, rather than the bridge econet uses,
> so it surprised, and pleased me, that it "just worked" without having
> to emulate a bridge as well.

Yeah, the Econet bridge is designed to be transparent: aside from asking
it for the local network number (if they care about that), the endpoints
never need to be aware of its existence.

> I'm still struggling a little with broadcasts, but I've not had much
> time to spend on it recently; it's only going to be something simple
> wrong,  Plus, I really need to find something relibale that uses them
> to test, lol.

Heh, right.  Something like *SERVERS is probably the easiest way of
exercising broadcasts.

> As soon as I get that sorted, I'll be ready to get the code off to
> Mike for inclusion in the released version.

Very good.  I'm somewhat ashamed to report that I haven't actually tried
out the BeebEm AUN bits yet, though I know Mark has had a go with them.
I guess we should try to find out why it doesn't seem to want to talk to
our bri^H^H^Hgateway at the moment.

p.