OKI 5200 looses connection after a few seconds 1

[bnsmhe]

WHo can help me?

We have an OKI 5200 printer which looses it's network connection after some seconds after plugging in the network cable. (You can't ping the printer anymore)
What I've tried to so solve it without success:
- Replaced the netwok card of the printer
- Replaced the linksys 224G switch with a HP procurve
- Changed the ip adres of the printer
- disabled all protocols on the printer except TCP/IP
- ...

However, when I replace the linksys switch with a 3Com 10Mbps HUB, everything works ( but pretty slow because of the 10Mbps).

Which other things could I check or test to resolve this. For me it looks like there is something on the network that's is blocking communications to the printer.
In all cases, the client computers worked fine.

Who can help me???

*************************
MCSA/MCSE 2000, MCSA 2003

 

[mattKnight]

Have you tried turning off auto-negotiation on the switch port?

Take Care

Matt
If at first you don't succeed, skydiving is not for you.

 

[jimbopalmer]

In general, a hub is a fixed speed, half duplex device; while a switch can be full duplex and can be autosensing for speed and duplex.

If the autosenseing and autonegotiating does not go well, it may be that the connection cannot be sustained; my experince is that it pings but has horrible throughput, your does not even ping.

If we assume the HP Procurve is managed you may wish to force that port to 100/half (which is faster) or 10/half (which will emulate your current hub) Due to an oddity in ethernet, one cannot force either end to full duplex unless one can force both ends. (The Oki website resists allowing one to read the manual, sorry)

I tried to remain child-like, all I acheived was childish.

 

[mattKnight]

Due to an oddity in ethernet, one cannot force either end to full duplex unless one can force both ends.

jimbopalmer Interesting, could you explain further?

Take Care

Matt
If at first you don't succeed, skydiving is not for you.

 

[jimbopalmer]

The FAQ I wrote years ago is in the Ethernet forum, so lets take another slant on the material.

The autosensing, autonegotiate protocol added to Ethernet is called N-Way: if the NIC sees certain electrical pulses when the circuit goes live, it can negotiate the fastest speed and duplex both NICs can do; if not, it falls back to half duplex. (this sometimes fouls us up if the bottleneck is not in a NIC, no part of N-Way tests the cable)

So if both sides are set to auto, we can do 100/meg Full Duplex or the fastest common protocol both NICs know. (Gig is ALWAYS full duplex, so it only needs to negotiate speed) If one side is locked to half duplex, N-Way 'fails' gracefully to provide a working half duplex link.

Sadly, if only one side is hard coded to full duplex, it will not send the pulses needed for N-Way to work. N-Way will default (incorrectly) to half duplex, and the link will be crippled.
(One side thinks it can send AND receive, one side thinks it can send OR receive, so there will be a huge number of protocol errors) I expect to get about 1% throughput on mismatched duplex.

So only hard code full duplex when you can set BOTH ends of the cable. (I rarely prefer no connection to reduced throughput as a sign of trouble, anyway)


I tried to remain child-like, all I acheived was childish.

 

[mattKnight]

Thank you for a clear explanation - It may be common knowledge, but its new to me and so worth a star!


Take Care

Matt
If at first you don't succeed, skydiving is not for you.