Wrote a full duplex tester which is really good at causing packet collisions.  It quickly caused the phone to not receive a packet for over 1 second.  It could legitimately be a delay from a wifi collision.  

The problem is compounded by the wrapping of all the  TCP packets inside another TCP connection inside wifi.  The only way it might work is by handling all the packets on the client & communicating with the phone in a simpler proprietary protocol, but TCP is already about as minimal as it can go.  At minimum, all the ACKs from Linux need to be discarded & all the ACKs from the phone need to be created on the client.  There's a lot of overhead from wrapping TCP inside TCP, but it might be bearable without all the ACKs.

The ACK filtering got the full duplex test working quite well but SCP was still as bad as before & TCP still had a lot of resends.   It's expecting to use the window size to throttle its sending speed instead of the delaying of the ACKs.  The next step would be asynchronously writing to the phone while sending ACK to the client so the ACK isn't delayed.  That would require a full flow control algorithm using the window size or enough RAM to buffer the largest file it would send.

That once again did nothing to speed up SCP but brought the number of resends down another notch.  Big websites typically don't have any more resends.  Only SCP has a small remaneing number of them.  It once again leaned towards artifacts of using multiple wifi hops or bugs in the Linux tun driver.

With performance being good enough, it was time to wrap it up.