sra@mitre-bedford.ARPA.UUCP (08/27/87)
I am under the impression that the new Bridge products implement RFCs 1001 and 1002. Of course they do not interoperate with other netbios implementations yet as they are the first to announce it. Stan Ames
ljm@TWG.COM (Leo J McLaughlin) (12/22/89)
There appears to be a difficulty in NetBIOS over TCP/IP's handling of simultaneous, duplicate name registration requests. If two nodes each ask for the same name at roughly the same time (for example if they are both coming up from the same power failure) both nodes will believe they own the name. This expected behaviour results from the stipulation in section 5.1.1.1 of RFC 1002, B-NODE ADD NAME, that names are not added to the local table until after the NAME REGISTRATION REQUESTS and NAME UPDATE REQUEST are sent and RFC 1002 section 5.1.1.5, B-NODE INCOMING PACKET PROCESSING, which requires that incoming NAME REGISTRATION REQUESTS be ignored until the name is added to the local name table. Furthermore, section 5.1.1.5 states that incoming NAME UPDATE REQUESTS have no effect other than to update the optional IP address cache. This issue is further clouded by a confusion within RFCs 1001 and 1002 about the name of this final name registration packet. Section 15.2.1 of RFC 1001, NAME REGISTRATION BY B NODES, shows a NAME OVERWRITE DEMAND rather than a NAME UPDATE REQUEST and Section 4.2 of RFC 1002, NAME SERVICE PACKETS, describes the existance of a NAME OVERWRITE DEMAND packet but no NAME UPDATE REQUEST packet, however, section 5.1.1 of RFC 1002, B-NODE ACTIVITY, the actual NetBIOS over TCP/IP B-node protocol specification, never mentions NAME OVERWRITE DEMANDS just NAME UPDATE REQUESTS. Note that the MAP/TOP NetBIOS over OSI specification avoids this difficulty by defining a 'being registered state' during which the name is defended from other name registration requests but doesn't answer to name query requests. If any implementors of NetBIOS over TCP/IP have dealt with this issue I would be interested in knowing if they came to the same conclusion about the NetBIOS specification and if they decided to implement name resolution as per RFC or if they fixed the problem.
marcelm@joymrmn.uucp (Marcel Mongeon (Admin)) (03/24/91)
I have Xenix-Net running over the Excelan NetWare product. The documentation indicates that it is running NetBios over TCP/IP in accordance with RFC's 1002 and 1003. I also have a DOS based machine in which I have an ethernet Lan card running a clarkson packet driver and NCSA Telnet. When instead of NCSA Telnet, I try to load up a Netbios product which talks with the packet driver (Specifically the Coconet product) I can communicate with other DOS machines configured in the same fashion. However, I cannot communicate with the Xenix-Net machines over NetBios even though the Telnet works fine. I think my problem is that the Coconet product is not using NetBios over TCP/IP but is instead just using bare NetBios. Is this correct? If it is correct, what implementation of Net Bios do I want for my DOS machines? Is there any Public Domain implementation that I could be using? -- ||| Marcel D. Mongeon ||| e-mail: ... (uunet, maccs)!joymrmn!root or ||| joymrmn!marcelm
jbvb@FTP.COM (James B. Van Bokkelen) (03/25/91)
I think my problem is that the Coconet product is not using NetBios over
TCP/IP but is instead just using bare NetBios. Is this correct?
It's using some proprietary transport protocol instead of TCP/IP; there isn't
really any such thing as "bare Netbios".
If it is correct, what implementation of Net Bios do I want for my
DOS machines? Is there any Public Domain implementation that I
could be using?
All the DOS TCP/IP Netbioses are commercial: FTP Software, Wollongong,
Excelan/Novell, Ungermann-Bass, CMC, Interlan. Any of them should talk
to the SCO product.
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901