Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Not VFP - MS Networking problem killing me
Message
From
12/01/1999 23:53:21
 
 
To
12/01/1999 22:47:50
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00175291
Message ID:
00175339
Views:
28
>Hi Ed,
>
>I see what you are saying, but I *need* TCPIP for my work contract connection and the Win98 Help said that IPX/SPX was a requirement on Win98 for successful connect with Win95 machines.
>But if/when it get really bad, I will try NetBeui only at night to find out.
>

I don't know the requirements of your work; if you say that you must run IP on your LAN, so be it. The IPX/SPX requirement is, for lack of a more polite term, a load of horse feces. IPX/SPX is used by NetWare; it can be used in a peer-to-peer environment to host NetBIOS over IPX/SPX. NetBEUI is a native NetBIOS-based protocol; there's no need in your environment to run IPX/SPX other than to host a NetBIOS session. If you're forced to run IP in any case, I'd investigate NBT (NetBIOS over TCP/IP, a good choice in NT environments, but a bit troublesome with Win95 in my own experience.

FWIW, unless you have a need to exchange IP packets between stations on your LAN, IP may not be necessary. It's easy enough to bind TCP/IP to a dial-up adapter; if the packets need not travel to other local stations, there's no need to bind IP to both the dial-up adapter and the LAN. In fact, it would be quite likely that a degree of complexity would be added that might be unpleasant, where your LAN IP address (a static, permanent addres since you don't have a machine to provide DHCP services) and your IP address on your dial-up adapter would be different (it's likely that any dial-up connection dynamically receives an IP address each time you make a connection) adding to the troubleshooting task.

The principle arguments in favor of TCP/IP and IPX/SPX are that the two protocols are routable; they can be carried across multiple LAN segments and routed to their destinations. NetBEUI is a broadcast-based protocol; it is designed to operate over a single segment, and not to be passed across a router, brouter or gateway to a different segment. It is as noted, a bit chatty (the stations under NetBEUI broadcast pckets to make themselves known, making it easy to identify NetBEUI participants with relatively little overhead. With a large number of stations, it generates a significant amount of traffic; you've got three nodes. Packets are small and have relatively little overhead in each packet, since routing and forwarding isn't an issue - it's nice and fast in small LAN environments. It's a simple stack, which imposes relatively little load on each PC as well - with either IP and NBT or IPX/SPX and NetBIOS over IPX, there are multiple software layers involved in processing each packet. There is no need for WINS resolution (the translation of NetBIOS names to IP addresses, the biggest issue for implementing NBT without an NT box to provide WINS services) since all stations use their NetBIOS name as their station identifier in packets.

I'd recommend the study guides for Microsoft's Network Essentials test - it covers the basics of protocols, media and network troubleshooting, and is a good general base to build on if you ever intend to get an MCSE. Any number of good books on the subject are available and are not heavily theory-oriented; the Microsoft curriculum is quite good.

My take on the matter is that with a small workgroup, NetBEUI is the fastest, easiest way to get the net up and running; there's a single protocol stack, the packet overhead is minimal, and there are no problems with station identifiaction and routing - assigning arbitrary IP addresses can cause all kinds of problems once you try to put your LAN out live to the Internet, since duplication of visible IP addresses can affect not only your site, but other sites as well.

In more complex environments, NetBEUI is far from the best choice of protocol. As the level of complexity goes up, and you introduce routing, dynamic addressig, proxy services (a mechanism that can hide some of your internal network IP addresses from the outside world, making all packets originating from your network appear to originate from a single IP address), TCP/IP becomes the protocol of choice. Without NetWare servers, IPX/SPX is rarely called for (even less so now that most networked games use TCP/IP as their preferred protocol; early on, games like Quake, Doom and Heretic had native support for IPX as their inter-machine communication protocol.)


>MORE INTERSPERSED
>
>>>>Hi All,
>>>>
>>>>Sorry this is not VFP, but this is the place I come for help, so...
>>>>
>>>>I have 3 machines in a MS Network setup using Ethernet cards connected with coax T-connections.
>>>>
>>>>I have been into the Properties of Network Neighborhood and REMOVED the network adapter, MS VPN, IPX/SPX..., NETBEUI..., re-booted and then re-installed all of that.
>>>>
>>>>Can anyone suggest some course of action to resolve this??
>>>>
>>>
>>> There's a lot of things that can cause problems. Whenever I have a problem on a coax network, I usually check the wiring and terminators first. If they check out OK, I move on to the machine having the problems. Wiring problems can cause some machines on the network to work OK, but others to have all sorts of bizarre problems - and the problems are not necessarily anywhere near the bad cable and/or terminator.
>>>
>>> Once that's checked, I suggest you get rid of NetBEUI, and IPX and just use TCP/IP. If that's not an option, I'd use IPX before using NetBEUI. NetBEUI can cause problems with some applications.
>>
>>I'd strongly disagree here. It's a single Ethernet segment. It's all Win9x. There's no proxy server, DHCP, or dedicated server. It's pure peer-to-peer, no routing. This is an ideal environment for nothing -but- NetBEUI. Low packet overhead, no need for central management. This is exactly netBEUI's turf; NetBIOS access and low packet overhead are called for. I'd dump everything but NetBEUI and work from there. With a TCP/IP stack, you still need a NetBIOS over TCP/IP in order to manage the environment; ideally, a WINS server should be present to resolve NetBIOS names to IP addresses. Why complicate things?
>>
>>Enable NetBEUI on all machines, and make sure that no other protocol binds to the LAN adapter. Give each machine a unique name, make certain that they're all using the same Workgroup, enable File and Printer Sharing on all machines and make the Win98 box the master browser (there are documented bugs involving in Win95's Master Browser code that can create exactly this situation.) Make sure that if any machine with a dual media NIC is set to select the coax connector; many cards default to using the RJ45 connector if no definitive selection is made.
>>
>All are using the same workgroup and all have unique names with *no* spaces/spec char in them. But the Computer description does have blanks and special chars in it. Hopefully that isn't material.
>*ALL* have Browse Master set to "automatic". Not finding anything as to what that is all about, that seemed a reasonable setting to me. Think I should change it???
>All cards have been working fine until this connection developed trouble. Odd too that the machine can be "seen" (ID and description show in NetHood) but attempt to access fails! SUggests that connection is acceptable to me.
>
>>Then deal with the standard brain damaged configuration things - make sure that all machine names are 16 characters in length or less, and that they don't contain special characters, especially spaces (it should not be a problem, but there's no good reason not to follow the NetBIOS naming conventions.) Mkae sure that each machine has a share of some sort to test connectivity from other machines - if nothing is visibly shared (especially if you've forgotten to enable File and Printer Sharing) Win9x browsers may not see the machine properly. Make certain that everything is terminated properly, and that only one of the terminators is grounded. Every machine goes through a T connector - don't bring the cable directly into the BNC connector, or you won't be able to terminate properly. Make certain that the calbes use a 50 ohm RG58 variant; lots of people can get away with using RG59 for a while, but impedance problems can and do crop up. Worry about password protection later, when
>>everything can see everything else.
>>
>Every machine does have a T-connector. File and Print sharing is enabled all around. Don't know about RG58 or RG59. No passwords ever set up - not for users at least, for sharing.
>
>Thanks Ed,
>
>Jim N
>
>
>>If things have3 gotten too complex, delete the NIC from the Win98 box in Device Manager (this will clear everything from Networking) and let Win98 readd the NIC and protocols. Limit yourself to NetBEUI when initially configuring the LAN. Again NetBEUI by itself is adequate; with TCP/IP or IPX, you need an additional NetBIOS layer to make the peer-to-peer environment work.
>>
>I'll probably have to try it this way. Tomorrow night.
>
>>>
>>> Do you have sharing enabled on all the computers? Have you tried to connect to a shared drive (on the computer that can't see the other two computers)? Open a DOS prompt and try: NET USE \\MachineName\ShareName
>>>
>>>You'll need to replace "MachineName" with the name of one of the computers that has a shared drive. "ShareName" is the name of the shared drive. Sometimes even though browsing doesn't work, you can still establish a network connection.
EMail: EdR@edrauh.com
"See, the sun is going down..."
"No, the horizon is moving up!"
- Firesign Theater


NT and Win2K FAQ .. cWashington WSH/ADSI/WMI site
MS WSH site ........... WSH FAQ Site
Wrox Press .............. Win32 Scripting Journal
eSolutions Services, LLC

The Surgeon General has determined that prolonged exposure to the Windows Script Host may be addictive to laboratory mice and codemonkeys
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform