On 11/1/2008 5:59 PM, Bernhard Rosenkraenzer wrote:
It's almost any connection -- and the few connections that do work don't seem to be related to the destination. It seems more related to transfer size:
*nod*
$ scp bero@xxxxxxxx:linux*tar.bz2 . Password: linux-2.6.27.2.tar.bz2 0% 0 0.0 KB/s - stalled -
I bet that if you sniff traffic on each end of the connection you will find that each end is sending packets and waiting for the other end to reply. I'll even go so far as to say that the "linux.cd" system (above) is even sending the reply packets in response to the last packet that it received from your client and that your client is *not* receiving said reply packet.
So, authentication works, and it definitely gets something back or it wouldn't know the filename -- but it stops and just sits there as soon as bigger amounts of data get transferred.
Ayup. This is sounding more and more like a path MTU / (TCP)MSS issue to me.
Like I said before (I don't know if you read the second half of my post.) try using the TCPMSS match extension / target and clamping the TCPMSS value.
It can't be a performance problem on the router - this is a quadcore box that is (currently) almost idle, and has virtually no traffic on either ethernet card.
I /seriously/ /doubt/ that the box is over loaded. Keep in mind that SMP has some of its own issues with IPTables. Though I don't think that is your problem here.
Grant. . . . -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
