mlsevResearch
asked on
How to resolve stalled inbound data transfers on sftp?
A unique problem has presented itself, upon inbound transfers via sftp...once the first 6Kb of a file has been transferred the connection stalls. If left to run, eventually it will complete but only after stalling after every 6Kb of data transferred.
system:
2.6.22.14-72.fc6 running openssh-4.3p2-25.fc6
Data transfer tests with/without IPTABLES running produce same behavior (stalled transfers). Data transfer tests to identical OpenSSH versions on other boxes via Gigabit LAN do NOT produce this behavior (stalled transfers).
Has anyone seen this before or know of a solution?
Thanks,
system:
2.6.22.14-72.fc6 running openssh-4.3p2-25.fc6
Data transfer tests with/without IPTABLES running produce same behavior (stalled transfers). Data transfer tests to identical OpenSSH versions on other boxes via Gigabit LAN do NOT produce this behavior (stalled transfers).
Has anyone seen this before or know of a solution?
Thanks,
ASKER
there are two boxes I'm receiving this error on so I'll paste sanitized output for both ifconfig & mii-tool:
box1:
ifconfig -> eth1
RX packets:12696 errors:1221 dropped:0 overruns:0 frame:1221
TX packets:4017 errors:0 dropped:0 overruns:0 carrier:0
mii-tool -> eth1
eth1: negotiated 100baseTx-FD flow-control, link ok
box2:
ifconfig -> eth1
RX packets:54276479 errors:7102653 dropped:0 overruns:0 frame:7102653
TX packets:89790299 errors:0 dropped:0 overruns:0 carrier:0
mii-tool -> eth1
eth1: negotiated 100baseTx-FD flow-control, link ok
all gigabit LAN traffic is for 192.168.0.0/27, connected to a LinkSys 8-port Gigabit switch
yes, I believe shielded cables are being used
box1:
ifconfig -> eth1
RX packets:12696 errors:1221 dropped:0 overruns:0 frame:1221
TX packets:4017 errors:0 dropped:0 overruns:0 carrier:0
mii-tool -> eth1
eth1: negotiated 100baseTx-FD flow-control, link ok
box2:
ifconfig -> eth1
RX packets:54276479 errors:7102653 dropped:0 overruns:0 frame:7102653
TX packets:89790299 errors:0 dropped:0 overruns:0 carrier:0
mii-tool -> eth1
eth1: negotiated 100baseTx-FD flow-control, link ok
all gigabit LAN traffic is for 192.168.0.0/27, connected to a LinkSys 8-port Gigabit switch
yes, I believe shielded cables are being used
Are these systems connected to the Gigabit switch? If so, mii-tool won't show the correct port settings as mii-tool is too old to know about GiE on copper ;)
OK, but we now know that there are no errors.
Try to switch the speed down to 100MBit/s or use unshielded cables for testing purposes (if available).
OK, but we now know that there are no errors.
Try to switch the speed down to 100MBit/s or use unshielded cables for testing purposes (if available).
ASKER
the ifconfig output I posted shows both devices have RX errors...which is exactly what's happening.
not able to swap out cables for testing, will look into what port speeds I can set on the switch...
I would argue that it's the switch but with all devices connected to the same switch yet only two in the mix are having RX errors?? That doesn't make sense...
not able to swap out cables for testing, will look into what port speeds I can set on the switch...
I would argue that it's the switch but with all devices connected to the same switch yet only two in the mix are having RX errors?? That doesn't make sense...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
agriesser, thanks for the previous responses as well as the latest detailed response. I'm in the process of getting information together concerning the cabling utilized for the GiE set-up to see where we're at...
so hopefully this solution will be solved shortly and points awarded...
so hopefully this solution will be solved shortly and points awarded...
ASKER
power-cycle of switch cleared the problems, thanks for all the help
I recently RMA'ed a Linksys 8-port GiBit switch due to some ill effects like you experienced. You should definetly think about replacing this switch...
Such errors could be caused by duplex mismatches and/or bad cables. Can you try to manually set the port mode for testing purposes?
On Linux, you could use the old `mii-tool` or the new `ethtool` (whatever is installed on your system) to set the port mode manually.
Do you have a 100MBit switch (or configured switch port) available for testing purposes? Gigabit Ethernet over copper sometimes causes very strange issues if the cables are shielded and I assume you're using shielded cables, right?