The great challenge was testing.  It ended up using an offline raspberry pi as a test client & the phone's access point as a test server.

On the test client, we have

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.12.0.1       0.0.0.0         UG    0      0        0 phone0
10.0.5.0        10.0.10.11      255.255.255.0   UG    0      0        0 eth0
10.0.10.0       0.0.0.0         255.255.255.0   U     0      0        0 eth0

Phoneproxy's virtual ethernet is the 0.0.0.0 gatway.  Then, we have to access the phone itself with a 10.0.5.0/24 net.  Finally, ssh into the raspberry pi requires a 10.0.10.0/24 net.

phone0: flags=4305  mtu 1500
        inet 10.12.0.1  netmask 255.255.255.255  destination 10.12.0.1
        inet6 fe80::284d:494d:ae58:cbec  prefixlen 64  scopeid 0x20
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)

The virtual ethernet is a 10.12.0.1/32 net to make it go to the phone for all but 10.12.0.1.

eth0: flags=4163  mtu 1500
        inet 10.0.10.11  netmask 255.255.255.0  broadcast 10.0.10.255
        inet6 fe80::dea6:32ff:fe94:a992  prefixlen 64  scopeid 0x20
        ether dc:a6:32:94:a9:92  txqueuelen 1000  (Ethernet)
        RX packets 8817854  bytes 1334993023 (1.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6952901  bytes 204012900 (194.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0:1: flags=4163  mtu 1500
        inet 10.12.0.2  netmask 255.255.255.255  broadcast 10.255.255.255
        ether dc:a6:32:94:a9:92  txqueuelen 1000  (Ethernet)

A test TCP server goes on the phone's access point 10.0.10.11.  It has 10.12.0.2.

Another test TCP server goes on a container on the development PC as a reference.

The test TCP server needs to do the basic tasks, open a connection, send from each side, close from each side, send large packets, stream multiple packets.

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

After the basic connection, transmit, receive, & close, the quality time with wireshark began.  It usually came to 1 corner case per day: failed DNS lookups, closing connections on the phone, packet fragmenting, multiple packets, cleanup after disconnecting the client.

TCP is quite a beast.  Lions only ever implemented ICMP & UDP before.

The mane problems were caused by timestamps.  Leaving out timestamps greatly simplified the algorithm.

When sending synthetic packets to the client, the phone needs to track how full the client window is by subtracting the ACK sequence numbers from the sent sequence numbers.  Then it needs to wait for enough ACKs before sending.  Some implementations only send 1 packet per ACK.  The phone actually ended up too slow to fill the client window.

The trick is testing out of order packets.  The packets are only in order when phoneproxy is running on the same machine as the browser.  It might be a reasonable requirement, since it's rarely going to be used & the phone accepts multiple connections.