Date : Sun, 05 Jul 2009 23:59:24 +0100
From : mu.list@... (Mark Usher)
Subject: econet bridge protocol
I have the start of a disassembly in an IDA file. (Interactive
DisAssembler). Not finished it though. Would be happy to put other peoples
bits and pieces together in a full disassembly and make the results known.
-Mark
> -----Original Message-----
> From: bbc-micro-bounces+mu.list=aon.at@... [mailto:bbc-
> micro-bounces+mu.list=aon.at@...] On Behalf Of Johan
> Heuseveldt
> Sent: 05 July 2009 23:45
> To: bbc-micro@...
> Subject: Re: [BBC-Micro] 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.
>
>
>
> _______________________________________________
> bbc-micro mailing list
> bbc-micro@...
> http://lists.cloud9.co.uk/mailman/listinfo/bbc-micro