Finally got full web browsing going on phone proxy.  It entailed deleting the default route on the phone's access point, toggling wifi on the phone to force it to use LTE.  Then run phoneproxy on the browser computer to direct it to the phone.

Adding support for duplicate packets, sorting out of order packets, & setting PSH everywhere possible got it loading all the big sites through phone proxy & the data plan.  It takes a while to get started, but eventually goes at full 5G speeds.  Either it's not practical for the phone company to disable this kind of proxy server or what lions did was really hard.  They could always disable all forms of I/O except LTE, making phones even more crippled than they already are. Imagine having to disable data in order to access a camera.

Setting the PSH flag was required to get useful latency in SSH, but was only possible from the phone to the PC.  It's not possible to force java.net.socket to set the PSH flag or get the PSH flag from java.net.socket. 

It doesn't seem to be getting any out of order packets & the packet sorting doesn't support more than 4GB per connection.  Handling sequence number wraparounds is a big deal.  4GB file transfers on this data plan are unlikely.  Good old telnet was essential for testing.

-------------------------------------------------------------------------------------------

SCP over phoneproxy starts at 800kbyte/s, then gets slower & slower after a fresh install of the phone app until it eventually hits dialup speed or stalls.  It actually doesn't return to 800kbyte/s until the app is reinstalled.  Restarting the app briefly gets it to 200kbyte/s.

Then the phone seems to close the phoneproxy socket after 2 minutes without activity.  Wireshark shows a lot of dup ACK & retransmissions from the client but no smoking gun when it stalls.  After cancelling, the phone sends out a lot of delayed ACKs which cause the client to send a lot of RST. 

SCP writes data to the phone concurrently with payloads from the phone.  A smarter protocol would bundle payloads from the phone in the ACKs to the client, but payloads to the phone requiring an ACK from the phone seem to be extremely rare compared to payloads from the phone.

There are multi second delays between some TCP sends from the client & the ACKs from the phone.  These cause resends after 200ms to 2 seconds.  The 200ms value is the TCP RTO & is not configurable.  The phone doesn't drop anything, but it needs the resends to kick the socket reads.  The resends are always client to phone.

Padding the space between packets with 0xff until they hit 1024 bytes actually boosts the initial speeds to 800kbyte/s, but it always drops back to dialup.

Setting TCP_NODELAY, setting all the PSH flags got higher speeds.  Nothing reduced the resends.

-----------------------------------------------------------------------------------------------

Large file HTTPS GETs from archive.org go smoothly with no resends & no need for padding.  Not padding the packets actually gets HTTPS up to 1MB/s.  Padding slows it down to 400kbyte/s.  Similar speeds happen with HTTP on the LAN.

Full duplex is where the problems are happening.