I'm trying to get some files transferred to my new SuSe Linux 9.0 from my old SuSe 6.4 via a simple switch. Both computers access internet ftp sites without any glitches (I have downloaded tons of files from the old one, and installed the new one via ftp), but when I try to connect the two of them troubles start. No matter which way I do it (1 -> 2, or 2 -> 1) the connection starts out fine, but very soon after it slows to a crawl and then halts completely.

I have disabled the SuSe-firewall on my new SuSe 9.0 - on the account that the main router does not allow any connections from the outside (stealth mode) - and this allowed me to use ssh between the two machines. I have also tried moving the files with scp, but the same error prevents me from copying large files. Smaller files gets through only because the connection starts out fine, and takes a second or two to drop from some 200+ KB/s to a complete halt.

Now what should I look at? I have tried tcpdump, but it doesn't really enlighten me as to what the problem is about.

I forgot to mention that both machines use DHCP, and the internal IP-numbers are 10.0.0.2, and 10.0.0.4, but I'm unsure whether this has anything to do with my troubles.

That seems odd.
Did you try to scp them?

Yes I tried both ftp, and scp, and the same thing happens: The connection is succesfull, but the bandwidth quickly falls to a halt. Even if I'm the only one using the 10/100 MBit network switch.

What's even more worrisome (if I have understood anything), is that my 'ifconfig -a' (it shouldn't really matter from which machine) says some 264 collisions only, and that was after many, many trials.

I'm most bewildered, but must admit that I'm not an expert on the tcpwrappers in inetd and xinetd respectively used on the two machines.

What is the output of
iptables -L -v -n;
from both machines.

Only my new machine uses iptables. When sending via ncftp to the new machine, the respons is:
Chain INPUT (policy ACCEPT 115 packets, 71579 bytes)
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
Chain OUTPUT (policy ACCEPT 121 packets, 8372 bytes)

The trouble must be on the new machine (SuSe 9.0), because scp only accepts connections from the new one to the old one. From old to new the connection is immediately refused.

Is this just some standard SuSe 9.0 security setting I've overlooked perhaps?

When fetching with scp from new to old (in which case the connection is accepted), only 60KB gets across then we're back to a completely stalled connection - "square one again".

No that just means that sshd is not started.
Run
/etc/initd/sshd start;
This has nothing to do with your original problem though. The only reason I was asking you to try scp was to rule out ftp as the problem. Since it is occurring on both ftp and scp I move to firewalls that might be throtling the connection down to prevent a DOS attack. Since that does not appear to be the problem let more towards datalink level. What is the output of
ifconfig -v;
On both machines.
Do you have a crossover cable?

command 'ifconfig -v' gives:
*OLD SuSe 6.4:*
eth0 Link encap:Ethernet HWaddr 00:00:70:24:60:3C
inet addr:10.0.0.4 Bcast:10.0.0.255 Mask:255.255.255.0
UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1
RX packets:40714 errors:0 dropped:0 overruns:0 frame:0
TX packets:14506 errors:0 dropped:0 overruns:0 carrier:0
collisions:118 txqueuelen:100
Interrupt:12 Base address:0xfcf0

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:3924 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0

*NEW SuSe 9.0:*
eth0 Link encap:Ethernet HWaddr 00:04:E2:54:BD:82
inet addr:10.0.0.2 Bcast:10.0.0.255 Mask:255.255.255.0
inet6 addr: fe80::204:e2ff:fe54:bd82/64 Scope:Link
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10763 errors:7 dropped:0 overruns:0 frame:7
TX packets:2018 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:4199952 (4.0 Mb) TX bytes:172274 (168.2 Kb)
Interrupt:10 Base address:0x1000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:178 errors:0 dropped:0 overruns:0 frame:0
TX packets:178 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:11432 (11.1 Kb) TX bytes:11432 (11.1 Kb)

No I do not own any crossover cable (unfortunately).

I think the source of trouble has been located and fixed: xinetd halts after a few seconds because it tries to start up as user '--default--'. When this value is set to 'root' in the conf. file (/etc/xinetd.d/services) xinetd starts up just fine. This became obvious when pressing "ctrl-alt-f10" for a view of the system logs (btw: can't these log-outputs be seen another way?).

Now if only I could get my old ethernet card up and running (for no apparent reason it has stopped working because the dhclient times out waiting for a valid dhcp-server response) so that I could verify the succes, my weekend would be saved.

Thanks a lot for all Your help. I'll reports back as soon as I know more.

The success has been confirmed. I've installed a new ethernet card on my old computer, and fixed the xinetd startup troubles, and now the connection works just fine.

SUCCESS: Remember to check the sytem log in /var/log/messages

Thanks a lot for all the tips and tricks :-)