How to negotiate an MTU larger than 1420 for the core device tunnel?

[zkj3e]

    async def request_tunnel_establish(self) -> Mapping:
        stream_id = self._quic.get_next_available_stream_id()
        # pad the data with random data to force the MTU size correctly
        self._quic.send_datagram_frame(b'h' * 1024)
        self._quic.send_stream_data(stream_id, self._encode_cdtunnel_packet(
            {'type': 'clientHandshakeRequest', 'mtu': 16000}))
        self.transmit()
        return await self._queue.get()

Setting the MTU to 16000, but receiving 1420 in response, how to negotiate an MTU larger than 1420 for the core device tunnel?

[doronz88]

I don't believe you can. This value is hard-coded in OS code

[zkj3e]

Why is the MTU of the tun established by remotepairingd set to 16000?

remotepairingd: (RemotePairing) [com.apple.dt.remotepairing:tunnelendpoint] tunnel-6: Starting packet transfer on <private>, MTU=16000, maxPendingPackets=32
remotepairingd: (RemotePairing) [com.apple.dt.remotepairing:virtualinterface] VirtualInterface: Read handler called without completion handler, dropping 1 packets
remotepairingd: (RemotePairing) [com.apple.dt.remotepairing:tunnelendpoint] tunnel-6: Packet transfer stats for <private>/<private>: written-to-interface=0, written-to-connection=0, read-from-interface=0, read-from-connection=0

utun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 16000
	inet6 xxx%utun4 prefixlen 64 scopeid 0x19 
	inet6 xxx prefixlen 64 
	nd6 options=201<PERFORMNUD,DAD>

[zkj3e]

Do we have anyway to know the 'clientHandshakeRequest' parameter for the handshake established by remotepairingd？

[doronz88]

You are correct, it seemed they have improved it. It requires further research. And nope, except for reversing

[doronz88]

Also, If you wish to try and improve the codebase, I advise you take a look at these other constratints:

https://github.com/doronz88/pymobiledevice3/blob/208e66a3cc44a67baa38171e8c1a9de633504aff/pymobiledevice3/remote/core_device_tunnel_service.py#L57

[zkj3e]

advise Thank you, please keep me updated on any progress.

[doronz88]

It appears they now support tcp as a transport protocol (in addition to quic) which then supports this MTU size. I'm still looking into it. If anyone wishes to help with the additional cryptography stuff then please contact my on the Discord

[doronz88]

Got everything working and the MTU is set to 16000 over the TCP protocol. You can test it with #694 but will have to wait for my other PR to be merged:

https://github.com/drbild/sslpsk/pull/28