Ethernet Errors - One Direction Only

[Dan Kaminsky]

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
execute:

FTP
===
1)  PUT from Windows to Linux
2)  GET from Windows to Linux(grab Serv-U FTP for Windows)

MTU
===
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
"limiting value"
2)  There's a MTU value within /proc/sys/net/ipv4 on the Linux box.  Fudge
that too.

NIC
===
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
systems.)

CD C:\WINDOWS
ATTRIB -R SYSTEM.*
ATTRIB -R USER.*
MKDIR REGBACK
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.

TCPDUMP
=======
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.

Yours Truly,

	Dan Kaminsky
	DoxPara Research
	http://www.doxpara.com