Stephen Munnings <steve@cormantech.com> wrote:
In article <9r58qh$4uv$> 1@nntp.qnx.com> >, > xtang@qnx.com > says…
Stephen Munnings <> steve@cormantech.com> > wrote:
In article
64F00D816A85D51198390050046F80C9012748@exchangecal.hq.csical.com> >,
RAllen@csical.com > says…
You are correct that IP over Arcnet is defined by RFC 1201; however, I’m
not buying the statement that an Arcnet driver could not be written for
QNX using the Network DDK. It seems to me that the source for ipfilter,
along with the Net DDK would provide all the information necessary to
write a RFC 1201 compliant Arcnet driver, would it not ?
The driver is not that hard…
But what about the ARP layer? It is different for ArcNet than for
Ethernet. It could be fudged, maybe, but would it work correctly?
ARP is currently in the IP-EN filter. If that is what you are referring
to as the “ipfilter”, then, yes, I believe that having the source to that
would be a large part of the “key” to doing this.
The only other (possible) problem that I am aware of, is that the ArcNet
drivers should be an instead of en, and I do not know if the tcpip
stack (either of them) could handle that properly.
This is still a practical issue. Does the tcpip stack(s) have all the
required support (if any) to handle an devices?
It is easy to say “it shouldn’t need to have anything”, but I have been
bitten with that thinking (both by me and by QSSL) before!
Is it verified that tcpip can handle the an interface names?
I have written a NetBEUI and an IPX stack for QNX4 and have also
maintained and modified several QNX4 network drivers.
I am currently working (on and off) on Ethernet and Arcnet drivers for
our cards for QNX6.
I have been through networking stuff quite thoroughly. And I have seen a
number of “gotchas” pop up when least expected.
Well, there always going to be “gotchas” until you finished 
The idea (of have a Y driver and “connect to Tcpip stack”) is
already tested by have a “ppp driver and a ip<->ppp converter”.
Without change of any part of stack, we just build a
“ip-ppp converter” which fold an IP packet into a PPP frame,
and a “ppp driver” which basically encode ppp frame and
write it out to serial port.
The stack do not care what name you gives a driver. It remember
the name (which the driver reported up), and the cell/endpoint/iface
of the driver.
“ifconfig xyz0 ip” will then tell stack assign ip address to
“that” driver. And then, when stack decided an ip should go
out throught “xyz0” interface (according the routing table),
it will send the ip packet to the cell/endpoint/iface.
One goal of new io-net design is so user could have their own
“driver X” or “protocal Y” and still take advantage (connect to)
existing protocol/drivers.
I think I understand the concepts. It is some of the (unpublished)
implementation details that are causing the concerns here.
All you need (in this case) is your own “Arcnet driver”, which
will put data on the wire; and, to connect to tcpip stack, you
need another parts called “ip <-> arc converter”, which convert
a IP packet to a “Arcnet packet” based on src/dst ip address.
(Remember, ARP, is just a way to “convert ip address into ethernet
address”)
That is its basic function. It also has to do other things - like
respond to the “arp” command with appropriate information. Also accept
information from the command, and put it into the ARP table (for ArcNet).
Is this interface documented/available?
(and in the case of ArcNet, handle the single IP packet to multiple
ArcNet packet conversion)
I am not ArcNet expert, but yes, if you decided to use “arp” in
ip <-> arcnet converter, you must handle the whole protocal, that
is, send/receive/reply the request. And yes, you want to table it
so next time the same ip address could be result in local cache
instead of put a (arp request) packet on wire. And ofcause, you
also need a timer to invalid the cache.
Another example… How does the tcpip stack know which interface or
filter to send a packet to based on the IP address? Does it simply
“broadcast it to all IP- filters”? or does it figure out which
filter or family of filters to send it to? If tcpip figures this out, it
must have some knowledge or interface to “talk to” the ARP layer (the IP-
XX filter). If it has such an interface (or does not), then this is one
of the “unpublished implementation details”.
As described above, the stack only remember the driver’s cell/endpoint/iface,
and send ip packet to there. How it end up to go though “ip <->arcnet
convert” but not “ip <->ether converter”, is because the io-net,
while assign cell/endpoint to a driver, it make sure it knows
which “path” it should use, when somebody send a packet to
drivers cell/endpoint/iface. (That is, io-net taking care of
how modules connect, according their above/below type, in registtration)
How you achive “ip <-> arc converter” is your problem. Either
it is a “Arp like, broadcast, wait for ack” thing, or you hard
code a IP <-> Arcnet list >
True, but there are other interface considerations - like above.
And, yes, the ideal is to have the ArcNet ARP as much like the Ethernet
ARP as possible. I.E. follow established best practices for Arcnet
TCP/IP as used in the rest of “the TCP/IP world”. Or, to put it another
way: To have as “seamless” an integration as possible.
It is same thing with “Protocal Y”, as long as you have a
“Y <-> ether converter”, the protocal Y could ride on any exist
ethernet driver.
Understood.
(But I am not planning on doing another NetBEUI! >
Why not NetBEUI and IPX on ethernet, that would be fun
-xtang