Has anyone done work in RTP for NetBeui?
I have to add some level of support for this protocol in a current
project.
At least I don’t have to mess with all the file and print stuff just
custom packet stuff.
Hi Larry,
As the author of a NetBeui protocol stack for QNX4, I feel I must reply!
What level of support do you need?
If you are only going to handle datagrams, name discovery and defending, and
other “non-session” messages, then you might have a good chance.
If you are going with full “session” support, then you better be at the guru
level!
The specs for NetBeui are available (from IBM, I believe - as part of OS/2
documentation) and the next-layer down LLC (only needed for “session” level
stuff) specs are available from IEEE. (neither is free)
Is there any reason you cannot use NetBios over TCP/IP? That is much
simpler, and has mostly already been done (Samba, and fs-cifs, etc.,)
You will also have the problem/issues of building a custom user-side API (a
somewhat modified NetBIOS), since the use of a software interrupt is (AFAIK)
not implemented in RTP (at least not yet).
Last, but not least, you will have the issues of building another network
protocol stack for RTP io-net. The RTP io-net doc covers “up-producers”
(i.e. network drivers) much more thoroughly than “down-producers” (i.e.
protocol stacks).
I have not done any NetBeui on RTP, but I am (off an on) working on an RTP
network (hardware) driver, and as mentioned before, I have written (in the
past, for another company) a NetBeui stack for QNX4.
Stephen Munnings
Corman Technologies Inc.
Larry Brigman <lbrigman@fcpa.fujitsu.com> wrote in message
news:3A43A64A.13B4E742@fcpa.fujitsu.com…
Has anyone done work in RTP for NetBeui?
I have to add some level of support for this protocol in a current
project.
At least I don’t have to mess with all the file and print stuff just
custom packet stuff.
“Steve Munnings, Corman Technologies” wrote:
Hi Larry,
As the author of a NetBeui protocol stack for QNX4, I feel I must reply!
What level of support do you need?
Only custom NETBIOS datagrams are needed, both send and reply.
About 15 to 20 command types.
If you are only going to handle datagrams, name discovery and defending, and
other “non-session” messages, then you might have a good chance.
If you are going with full “session” support, then you better be at the guru
level!
The specs for NetBeui are available (from IBM, I believe - as part of OS/2
documentation) and the next-layer down LLC (only needed for “session” level
stuff) specs are available from IEEE. (neither is free)
Is there any reason you cannot use NetBios over TCP/IP? That is much
simpler, and has mostly already been done (Samba, and fs-cifs, etc.,)
I’m going to be using fs-cifs to get the files for these test nodes. It is
that I’m trying to us an existing application on the host side that already
supports
these functions. The host side allows us to hook-up to existing Oracle
Applications.
You will also have the problem/issues of building a custom user-side API (a
somewhat modified NetBIOS), since the use of a software interrupt is (AFAIK)
not implemented in RTP (at least not yet).
Last, but not least, you will have the issues of building another network
protocol stack for RTP io-net. The RTP io-net doc covers “up-producers”
(i.e. network drivers) much more thoroughly than “down-producers” (i.e.
protocol stacks).I have not done any NetBeui on RTP, but I am (off an on) working on an RTP
network (hardware) driver, and as mentioned before, I have written (in the
past, for another company) a NetBeui stack for QNX4.Stephen Munnings
Corman Technologies Inc.Larry Brigman <> lbrigman@fcpa.fujitsu.com> > wrote in message
news:> 3A43A64A.13B4E742@fcpa.fujitsu.com> …
Has anyone done work in RTP for NetBeui?
I have to add some level of support for this protocol in a current
project.
At least I don’t have to mess with all the file and print stuff just
custom packet stuff.
Hi Larry,
Well, It should be do-able: if you only need Datagram support.
However…
Are you sure you need NetBeui (which is a particular implementation of
NetBios at the wire level) rather than just using NetBios over TCP/IP (a
different NetBios implementation that uses TCP/IP underneath as the wire
level protocol)?
If the host-side is M$ or IBM OS (and many others) it is very likely that
the application simply uses NetBios, and the OS configuration is set up to
use any or all of a number of different wire level protocols to carry the
messages. The fact that you are using fs-cifs in RtP would indicate that
the host is already configured with NetBios over TCP/IP.
It may (or may) not also use NetBeui. It is also very likely then that the
app you wish to communicate with does not care if it is NetBeui or NetBios
over TCP/IP, it just asks the NetBios protocol stack to do the appropriate
datagram messaging.
If it uses NetBios over TCP/IP, then you can find the specs in RFC 1001 and
1002 (if memory serves me correctly) and simply code your program to use
standard TCP/IP services (and follow the RFCs for the format and meaning of
the messages).
That should be light-years simpler that using NetBeui and your own protocol
stack.
In fact, I am not sure how my boss feels about it, but it is possible that
we might be able to do it for you (for the right price, of course!).
Stephen Munnings
Corman Technologies Inc.
Larry Brigman <lbrigman@fcpa.fujitsu.com> wrote in message
news:3A54F68B.3F17F87B@fcpa.fujitsu.com…
“Steve Munnings, Corman Technologies” wrote:
Hi Larry,
As the author of a NetBeui protocol stack for QNX4, I feel I must reply!
What level of support do you need?
Only custom NETBIOS datagrams are needed, both send and reply.
About 15 to 20 command types.
If you are only going to handle datagrams, name discovery and defending,
and
other “non-session” messages, then you might have a good chance.
If you are going with full “session” support, then you better be at the
guru
level!
The specs for NetBeui are available (from IBM, I believe - as part of
OS/2
documentation) and the next-layer down LLC (only needed for “session”
level
stuff) specs are available from IEEE. (neither is free)
Is there any reason you cannot use NetBios over TCP/IP? That is much
simpler, and has mostly already been done (Samba, and fs-cifs, etc.,)I’m going to be using fs-cifs to get the files for these test nodes. It
is
that I’m trying to us an existing application on the host side that
already
supports
these functions. The host side allows us to hook-up to existing Oracle
Applications.
You will also have the problem/issues of building a custom user-side API
(a
somewhat modified NetBIOS), since the use of a software interrupt is
(AFAIK)
not implemented in RTP (at least not yet).
Last, but not least, you will have the issues of building another
network
protocol stack for RTP io-net. The RTP io-net doc covers “up-producers”
(i.e. network drivers) much more thoroughly than “down-producers” (i.e.
protocol stacks).I have not done any NetBeui on RTP, but I am (off an on) working on an
RTP
network (hardware) driver, and as mentioned before, I have written (in
the
past, for another company) a NetBeui stack for QNX4.Stephen Munnings
Corman Technologies Inc.Larry Brigman <> lbrigman@fcpa.fujitsu.com> > wrote in message
news:> 3A43A64A.13B4E742@fcpa.fujitsu.com> …
Has anyone done work in RTP for NetBeui?
I have to add some level of support for this protocol in a current
project.
At least I don’t have to mess with all the file and print stuff just
custom packet stuff.
“Steve Munnings, Corman Technologies” wrote:
Hi Larry,
Well, It should be do-able: if you only need Datagram support.
However…
Are you sure you need NetBeui (which is a particular implementation of
NetBios at the wire level) rather than just using NetBios over TCP/IP (a
different NetBios implementation that uses TCP/IP underneath as the wire
level protocol)?
I asked this question of the vendor the other day. The answer is that
they are using NetBeui because of the hooks that LLC allows them to
do; show and control a remote terminal. The rest of the support does
not need this level but is currently locked into NetBeui.
If the host-side is M$ or IBM OS (and many others) it is very likely that
the application simply uses NetBios, and the OS configuration is set up to
use any or all of a number of different wire level protocols to carry the
messages. The fact that you are using fs-cifs in RtP would indicate that
the host is already configured with NetBios over TCP/IP.
We have to have both protocols loaded on the M$ host side as the current
client is DOS and can only talk NetBeui after the Bootp OS load.
The vendor is willing to work with me on source code for the custom data packet,
so I do have a start.
Right now I working at both ends of the spectrum. I trying to do proof of
concept
and trying to figure out what would or could be the road blocks for all of
this to work.
In fact, I am not sure how my boss feels about it, but it is possible that
we might be able to do it for you (for the right price, of course!).Stephen Munnings
Corman Technologies Inc.Larry Brigman <> lbrigman@fcpa.fujitsu.com> > wrote in message
news:> 3A54F68B.3F17F87B@fcpa.fujitsu.com> …
“Steve Munnings, Corman Technologies” wrote:Hi Larry,
As the author of a NetBeui protocol stack for QNX4, I feel I must reply!
What level of support do you need?
Only custom NETBIOS datagrams are needed, both send and reply.
About 15 to 20 command types.
If you are only going to handle datagrams, name discovery and defending,
and
other “non-session” messages, then you might have a good chance.
If you are going with full “session” support, then you better be at the
guru
level!
The specs for NetBeui are available (from IBM, I believe - as part of
OS/2
documentation) and the next-layer down LLC (only needed for “session”
level
stuff) specs are available from IEEE. (neither is free)
Is there any reason you cannot use NetBios over TCP/IP? That is much
simpler, and has mostly already been done (Samba, and fs-cifs, etc.,)I’m going to be using fs-cifs to get the files for these test nodes. It
is
that I’m trying to us an existing application on the host side that
already
supports
these functions. The host side allows us to hook-up to existing Oracle
Applications.
You will also have the problem/issues of building a custom user-side API
(a
somewhat modified NetBIOS), since the use of a software interrupt is
(AFAIK)
not implemented in RTP (at least not yet).
Last, but not least, you will have the issues of building another
network
protocol stack for RTP io-net. The RTP io-net doc covers “up-producers”
(i.e. network drivers) much more thoroughly than “down-producers” (i.e.
protocol stacks).I have not done any NetBeui on RTP, but I am (off an on) working on an
RTP
network (hardware) driver, and as mentioned before, I have written (in
the
past, for another company) a NetBeui stack for QNX4.Stephen Munnings
Corman Technologies Inc.Larry Brigman <> lbrigman@fcpa.fujitsu.com> > wrote in message
news:> 3A43A64A.13B4E742@fcpa.fujitsu.com> …
Has anyone done work in RTP for NetBeui?
I have to add some level of support for this protocol in a current
project.
At least I don’t have to mess with all the file and print stuff just
custom packet stuff.
Hi again Larry,
Are you sure you need NetBeui (which is a particular implementation of
NetBios at the wire level) rather than just using NetBios over TCP/IP
(a
different NetBios implementation that uses TCP/IP underneath as the wire
level protocol)?I asked this question of the vendor the other day. The answer is that
they are using NetBeui because of the hooks that LLC allows them to
do; show and control a remote terminal. The rest of the support does
not need this level but is currently locked into NetBeui.
o.k. so you do indeed need NetBeui…
Since you are only planning to use datagrams, that will simplify life
considerably!
Technically, you still are using LLC layer protocol underneath, but unless
the packets are parts of sessions, the LLC based stuff in the packet is
simply a bunch of constant information.
If the host-side is M$ or IBM OS (and many others) it is very likely
that
the application simply uses NetBios, and the OS configuration is set up
to
use any or all of a number of different wire level protocols to carry
the
messages. The fact that you are using fs-cifs in RtP would indicate
that
the host is already configured with NetBios over TCP/IP.
We have to have both protocols loaded on the M$ host side as the current
client is DOS and can only talk NetBeui after the Bootp OS load.The vendor is willing to work with me on source code for the custom data
packet,
so I do have a start.
That is good!
Right now I working at both ends of the spectrum. I trying to do proof of
concept
and trying to figure out what would or could be the road blocks for all of
this to work.
Well, hopefully the info I already gave you will help here. If you need
more detailed info, I can give you what I remember if you either call me or
e-mail me.
(519) 884-4430 x718 or steve@cormantech.com