Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Register Log in
  • Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

CE100B.LAN (DELL 4600 Server) NetWare 5.1

Status
Not open for further replies.
marvhuffaker

marvhuffaker

MIS
Joined
Jun 25, 2003
Messages
2,949
Location
US
Does anyone know of any issues with the CE100B.LAN module (CE100B.LAN v8.02 Sep. 30, 2003 Intel(R) 8255x-based Network), which I believe was distributed in NW5.1 SP7?

I am having client connectivity issues and believe that the NIC is not neglecting to respond to certain client requests which results in dropped connections.

Marvin Huffaker MCNE, CNE
Marvin Huffaker Consulting, Inc.
 
Sort by date Sort by votes
sorry never worked with dell's - well only once

the card sounds familar though
 
Upvote 0 Downvote
I re-read my post and realize that I didn't make much sense..

The problem is that clients are dropping at random. My thoughts are that the server is not responding to workstations requests. Therefore, the workstation thinks the connection has gone bad and kills it.

Marvin Huffaker MCNE, CNE
Marvin Huffaker Consulting, Inc.
 
Upvote 0 Downvote
Hi

Check the Nic is set at 100 Full duplex and have the comms guys check the switch that it is the same. Seen problems when a server is built on a test bed at 10 half then goes into production and for some reason picks up 100 half. It causes all soughts of problems including what you describe.
Check the server for high utilization. Check all the workstation are set to 100 full - No AUTO on your nic cards and again have comms check teh ports if they are found to be set at Auto.

Good luck

David
 
Upvote 0 Downvote
Generally as a rule, servers and their switch ports have to be forced. Workstations and their switch ports can be left at auto negotiate as they will negotiate to 100Mb Full Duplex.

Also, workstations set to auto negotiate connected to a forced 100Mb full duplex switch port will not auto negotiate to 100Mb full duplex, it will only negotiate to 100Mb Half Duplex.

-----------------------------------------------------
"It's true, its damn true!"
-----------------------------------------------------
 
Upvote 0 Downvote
Thanks for the input. I have covered these bases very thoroughly.. Server/switch are forced.. Workstations are Auto. Although I have tried various settings including forcing workstations to 100/full and also changing server NIC to Auto. Doesn't seem to make a difference. The drops still occur. Based on certain things I have seen, I am starting to believe it is a server problem, not a workstation issue.

More than anything I was hoping that maybe someone knew of a specific defect list for this driver and it's various versions. I suspect a defect but haven't been able to capture a trace yet because it happens so random and sporadically. (being at "THE" workstaiton that craps out is the challenge since they are so random)

I know there are newer versions of this driver but would like to find out what documented issues are resolved before applying it. (or even just someone else that may have had the same issue)

To David -- it's funny because over the years the arguments fly regarding auto or forcing full/100.. Some people insist on Auto, others insist on Forcing. Nobody can come to a 100% sure fire answer that works all the time.. So what's the rule? Who knows.. I've come to the conclusion that it depends on the Make and Model of switch, and what the manufacturer recommends. But I sure feel sorry for you if you are manually setting all of your workstations to 100/full.. That's a lot of extra work (depending on how many workstations you're talking about).


Marvin Huffaker MCNE, CNE
Marvin Huffaker Consulting, Inc.
 
Upvote 0 Downvote
Marv - you could always ping the suspect server from another server to see whether the ping results are 100% or not?

-----------------------------------------------------
"It's true, its damn true!"
-----------------------------------------------------
 
Upvote 0 Downvote
That's a good idea.. I actually did do that a while ago, but it was to a server across a slow WAN.. So when it started failing I naturally blamed Qwest. Didn't think anything more of it (I wasn't actually chasing this specific problem at the time).

I could setup something on the LAN and see what happens. Thanks.

Marvin Huffaker MCNE, CNE
Marvin Huffaker Consulting, Inc.
 
Upvote 0 Downvote
Marvin, is the workstation crossing a WAN link? I saw something similar when a router wasn't forwarding watchdogs from the server correctly.
 
Upvote 0 Downvote
No WAN links from workstation to server.. I did find in some packet traces from the workstation that there are numerous checksum errors. It appears that the workstation is responding to the server telling it that a previous packet it received was invalid.. But I'm not too sure.


Marvin Huffaker MCNE, CNE
Marvin Huffaker Consulting, Inc.
 
Upvote 0 Downvote
Also, check that the subnet mask is correct as I remember seeing this in a server that was configured with the wrong mask for the IP subnet.

-----------------------------------------------------
"It's true, its damn true!"
-----------------------------------------------------
 
Upvote 0 Downvote
Ok, I doublechecked with the LAN guy for this company to check the switch settings and find out about any errors.. This is what I found.. Yes, there are errors on the Server's port. No he cannot tell what the errors are, he's just looking at some graph. The Switch port is running at 100/Full; and the Server is running at 100/Full.

However, both are set to AUTO negotiate. Could this contribute to the problem? It's a 3COM 24port switch, model 3C16980.

I know that the server is set to AUTO because this client used to have a cheap netgear switch that would only work in AUTO.. They put the server on a different switch to try to eliminate the problem. It doesn't seem to have changed anything.



Marvin Huffaker MCNE, CNE
Marvin Huffaker Consulting, Inc.
 
Upvote 0 Downvote
Well, aside from a faulty server NIC or even a faulty port on the switch or even faulty cabling (structured cabling or patch leads), it could be the server configuration at fault :)

-----------------------------------------------------
"It's true, its damn true!"
-----------------------------------------------------
 
Upvote 0 Downvote
Did the client use "set maximum physical packet receive size = 1514" as used to be in fashion? I remember tht Intel chipsets on NICs did not work right if that was set. It doesn't need to be set in any case.
 
Upvote 0 Downvote
Marvin, did you ever resolve this? What was the cause?
 
Upvote 0 Downvote
I did get this resolved... Sort of. But I beleive it is more of a band-aid than anything else.

It is my hunch that there is a bug in the client that hasn't been identified. Or if it has, a solution hasn't been found. The bug causes certain clients to drop due to some event or condition that occurs on the network. I thought it was one specific workstation type,but found out that it occurs on various workstation models and NICS.

Catching this problem in action is extremely difficult. Whenever I tried to sniff a workstation with ethereal, the problem never occurred. It's like whatever ethereal was doing, (or maybe winpcap), it prevented the problem from happening. Talk about frustrating.

What's happening is that something is causing the workstation to think that the server is down. The server name is entered into the "Bad Name Cache" on the client. This forces the client to drop the connection. After so many minutes, the cache flushes and it's possible to reconnect. That's why sometimes if you wait long enough, the connection will come back. But most people don't, and just reboot.

So the 'solution' is to turn off the Bad Server Name Cache and set the bad address timeout and bad server timeout to 0. Also ensure the auto-reconnect is set to on. This will force the client to reconnect even if prior attempts to the server have failed. At least it keeps the connection alive. These settings are only avaialble in 4.9 SP2 or higher. (There may have been reghacks available on earlier versions, but it's actually in the settings on 4.9sp2). There must have been enough people having the problem...

Marvin



Marvin Huffaker, MCNE
 
Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

wavestar69
  • Locked
  • Question Question
Trouble starting WinFrame 1.7 after replacing server
Replies
0
Views
667
wavestar69
wavestar69
joemamps
  • Locked
  • Question Question
Netware 5 slow btrieve transaction after nw50sp6a update.
Replies
1
Views
549
Provogeek
Provogeek
dumbchemist
  • Locked
  • Question Question
Using IDE to SATA/SATA to IDE converters with Netware 5
Replies
18
Views
2K
goombawaho
goombawaho
ChuckWoodbury
  • Locked
  • Question Question
Adding Netware 5.1 Server to Existing Tree
Replies
8
Views
696
goombawaho
goombawaho
jimbo2364
  • Locked
  • Question Question
Novell NetWare Server 65. Server name locations
Replies
2
Views
404
lgarner
lgarner

Part and Inventory Search

Sponsor

Back
Top