ccrawford at atsengineers.com
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
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