network resources

Charles Crawford ccrawford at
Tue Dec 19 17:24:35 GMT 2000

Are you sure this is not the problem?  Red Hat systems will execute
a reverse lookup on all tcp connection attempts, and the connection
will be held up pending this lookup or a time-out.  If you really want
to be sure this isn't the problem, verify that a telnet attempt from
the same Windows client does not exhibit a long lag before prompting
for a login.  You will always be able to ping by IP, whether your
reverse lookups work or not.

-OK, this looks like what is happening, but that does not explain the Samba
delays, or does it?
The traceroute shows it going directly to the host/client/server...

Try a traceroute?  I find it hard to believe this is happening.

> The response time being doubled indicates to me that the traffic is
> traveling twice the distance, not being held up somewhere... BTW, it
> is EXACTLY twice the time, so I think that that indicates an extra
> trip for each packet to the destination machine.

This could easily be something else, though.  What about half vs.
full-duplex network cards/drivers and/or 10/100 and hub/switch
differences?  Assuming it is a network issue, is the route to and
from each of these machines through the same type of equipment?

These are all full-duplex cards with the correct drivers, Cisco switches set
to full-duplex as well and all equipment is uniform from end to end. (except
that the client machines are very different from the server machines [Dell
PowerEdge servers and mixture of Crappy/Great client machines
(MidwestMicro/Dell Optiplex)].

Oh well, maybe I'll upgrade the Linux boxes with a 7.0 upgrade and the
latest Samba code. I'll try a test machine first though.

If you're running RH, watch the errata:
(There was a 6.2 FTP exploit fix released in June.)

Thanks for the link.


More information about the samba-technical mailing list