Ethernet Errors - One Direction Only
effugas at best.com
Wed Jan 5 03:25:24 GMT 2000
OK, I'm game for solving this one...
If Linux pulls, the transfers work.
If Windows pushes, the Linux box gets DOS'd.
Well, if the Linux box was specifying a different block size/type when it
pulled the data than when Windows was pushing it, it would explain the
unidirectionality of the failure. Here are some further tests for you to
1) PUT from Windows to Linux
2) GET from Windows to Linux(grab Serv-U FTP for Windows)
1) Go to www.nonags.com and find a tool to change your MTU(Maximum
Transmission Unit) value. You've got a range from 522 to 1500 bytes per
packet. If either extreme "just works", oscillate by halves(10 fails, 5
works, 8 fails, 7 works--7 is highest value that works) until you find the
2) There's a MTU value within /proc/sys/net/ipv4 on the Linux box. Fudge
1) Change the NIC on the Windows machine--use the following commands to
save your registry before you futz w/ your drivers, and you'll be able to
go back painlessly. (I always do this before I blast apart people's
ATTRIB -R SYSTEM.*
ATTRIB -R USER.*
COPY SYSTEM.* REGBACK
COPY USER.* REGBACK
2) Change the NIC on the Linux machine. This is my prime culprit--I'm
betting the drivers on the Linux side aren't coping with some signal
they're getting from the Windows side. (We operate on a higher standard
in Linux--this instability has a DoS Security Breach
Flipside.) Preferably, toss in a tulip and after the system boots, just
run insmod tulip.
Can you get us some tcpdump -e traces of the network failures?
Try these, and get back to us. We'll see where we stand from there.
More information about the samba-technical