Date : Mon, 06 Jul 2009 00:45:02 +0200 (BST)
From : johan@... (Johan Heuseveldt)
Subject: econet bridge protocol
Hi Phil,
On Sat 04 Jul, Phil Blundell wrote:
> Disassembling the bridge ROM presumably would reveal the truth but I was
> hoping to avoid having to do that. :-}
>
> However... looking back in my mailbox I see that Johan Heuseveldt was
> working on a disassembly about four years ago. Johan, how far did you
> get with that?
Not so far...
I started with the schematics, and 90% was easy. Next 5% was
much harder, and last 5% however, I was unsuccessful: I couldn't
make of any sense of the actual network wiring between the two
networks. As I couldn't figure this out, I had the feeling it
wasn't wise to put myself into the software side.
I think I must have the draft of the hardware, including my
impossible findings. If there's an interest, I can put them
somewhere on my site for grabbing. Low quality ISTR.
> I don't think disassembling the MDFS ROM would help much; I don't think
> the MDFS has any explicit relationship with the bridge or, at least, I
> can't think of any reason why it would need to.
Sounds logical.
In principal the bridge protocol is transparent to the stations.
When a bridge receives a first scout, and the other network needs
to be accessed, it's the bridge putting the first network to flag
filling, so no one can interfere. When a station on the second
network response - first flag filling, then transmitting that
response - the bridge is the receiver now, and sets the second
network to flag filling and relays that response on the first
network to the originating station, by switching to transmition,
thereby withdrawing the flagfilling it was doing sofar. Etc.
Obviously, the bridge needs to queue all data in between.
When both the networks has the same speed, the overall speed is at
least halved!
The problem I encountered during reverse engeneering the PCB
for a schematic, was seeing some wires of the two networks
connected together, leaving me completely baffeled, as it suggests
a hardware connection too between the two networks???
(I must be overlooking something here)
> On Sat, 2009-07-04 at 21:52 +0100, Chris Thornley wrote:
> > Perhaps it used in building an equavilent of a routers CAM table i.e. a map
> > of where networks are so routes can be looked up
> > Like using address 1.xxx 2.xxx denotes the network xxx is the station
> > number.
During its life being powered up, the bridge keeps a list of known
network numbers as soon as aware of, as it starts knowing only its
own two network numbers.
> > Does anybody have documentation on the port &9c protocol used by bridges?
> > Chapter 10 of the MDFS book gives some details but doesn't describe the
> > messages with control bytes &80 and &81.
It doesn't even mention if they exist at all! (afaics)
Also, a reset packet is mentioned, without further clarification.
The other two (&82/&83) are explained properly I reckon.
> > Observing the single bridge that I have here, at power up it seems to send a
> > broadcast with control byte &80, containing in its payload the number of its
> > other local network; I guess this is the "reset packet"
> > that the MDFS book talks about.
No idea, as the existeance of a reset package is only mentioned. No further
details. Have not found it elsewhere.
> > If I send the bridge one of those packets (cb &80) then it responds with a
> > series of packets with control byte &81 and, again, the network number of
> > its far side in the payload. I'm not entirely sure what the meaning of
> > these packets is, or how (if at all) I am meant to respond to them.
That's perhaps the communication between bridges?
At some point, bridges need to know about networks other than adjecent.
It does monitor traffic when idle, but most likely has its own protocols
as well. (cb &80/&81)
> > Can anybody shed any light on that? Or, absent any documentation, is there
> > anybody with two or more bridges who would be prepared to capture some
> > packet dumps showing them talking to each other?
I have several bridges; 2x Acorn, 1x SJResearch, but I have no clue
how to capture these packets. In case you have specific sw to do so,
let me know off list. Using Netmon is doable, but needs a lot of know
how and expertise knowing where to look for, and how to interpret the
data I guess.
(and Netmon does /not/ show /all/ the data!)
About a disassembly, I should be able to generate one automatically.
If needed, wanted, makes one of you happy...
Greetings,
Johan
--
Johan Heuseveldt <johan@... >
aka waarland
The best place is a Riscy place
That boogie woogie woogie really sweeps me off my feet.