Very Computer

Hello,

I have a weird network problem. I have 2 linux machines connected. The
other one is connected to internet (call it server) and the other (client)
is a masquerade client. The two machines are connected with ethernet. The
problem is, that I can transfer files from server to client just fine,
but the other way around, ie. from client to server no data is being
transfered. I've tried ftp, nfs and samba to no avail. I can use ssh and
vnc to connect to the server from client and I can send _short_ mails
from the client machine, but if I try to send a longer mail the mail will
not be sent. So it seems like little amounts of data can be transferd,
but thats it.

I'm totally confused with this problem. Is it possible that it's a
hardware problem? Or could it be something with the setup? If someone has
any idea please help. I can give information on my setup if I know what
to tell.

Simo

Can you come up with a reasonably simple test to demonstrate the
problem, maybe something HTTP orientated, but anthing really.

Run a tcpdump on one or both of the machines attached to the
interfaces that are in use. use the -n switch to remove DNS lookups.
compare the two outputs and see where if starts to fail. If you can't
find where its going wrong then email it.

karl.

Here is the result of running 'tcpdump -n -i eth1' on the server machine
192.168.0.1 when I try to copy a 12kb textfile from the client machine
192.168.0.10 harddrive to a nfs mounted share of the server machine. I
can't make out anything of it. The result of this copy attempt is a
0 byte file on the server.

tcpdump: listening on eth1
17:54:25.834840 192.168.0.1.22 > 192.168.0.10.32785: P 1825721078:1825721126(48) ack 1436307115 win 10744 <nop,nop,timestamp 9475979 135835> (DF) [tos 0x10]
17:54:25.835301 192.168.0.10.32785 > 192.168.0.1.22: . ack 48 win 41992 <nop,nop,timestamp 135837 9475979> (DF) [tos 0x10]
17:54:31.272268 192.168.0.10.1803607038 > 192.168.0.1.2049: 104 getattr [|nfs] (DF)
17:54:31.272677 192.168.0.1.2049 > 192.168.0.10.1803607038: reply ok 112 getattr DIR 40755 ids 1000/1000 [|nfs] (DF)
17:54:31.273417 192.168.0.10.1820384254 > 192.168.0.1.2049: 124 lookup [|nfs] (DF)
17:54:31.273849 192.168.0.1.2049 > 192.168.0.10.1820384254: reply ok 232 lookup [|nfs] (DF)
17:54:31.274757 192.168.0.10.1837161470 > 192.168.0.1.2049: 152 setattr [|nfs] (DF)
17:54:31.275138 192.168.0.1.2049 > 192.168.0.10.1837161470: reply ok 144 setattr [|nfs] (DF)





17:55:11.118570 192.168.0.10.32785 > 192.168.0.1.22: P 1:49(48) ack 48 win 41992 <nop,nop,timestamp 140365 9475979> (DF) [tos 0x10]

14 packets received by filter
0 packets dropped by kernel

Quote:> Can you come up with a reasonably simple test to demonstrate the
> problem, maybe something HTTP orientated, but anthing really.

> Run a tcpdump on one or both of the machines attached to the interfaces
> that are in use. use the -n switch to remove DNS lookups. compare the
> two outputs and see where if starts to fail. If you can't find where its
> going wrong then email it.

> karl.

things upto here are going fine.

packets are coming from the client fine, but no replies are being
sent back there. Due to the tcpdump running on the server end
(destination) I would suspect either the packets are rubbish
possible checksum errors, with ethereal you can easily spot it
(www.ethereal.com) or firewall settings on the server
(iptables -L/ipchains-L).

It is happens with all protocols then I would check with ethereal
output,of exactly the same test, I don't know how check checksums
with tcpdump off hand.

karl.