Wireless tunnel connection

[karthikgbbristol]

This might be a feature request and not a bug!

I have noticed that on some iOS devices, the tunnel stays open and connected when disconnected. Assuming the device and PC are on the same network, I'd still be able to use the tunnel details when the device is disconnected from PC.

This behaviour is not consistent though.

I have an iPhone 15 Pro Max running 18.2, on which the tunnel drops when the cable is disconnected. On an iPhone 16 device running 18.1.1, the tunnel remains open when disconnected.

Can I force the tunnel to stay on when the cable is disconnected?

[karthikgbbristol]

When I disconnect the device I get this error in the console

{"level":"info","msg":"C:\windows\system32\netsh.exe interface ipv6 set address tun0 fd80:9c5d:7085::2/64","time":"2024-12-13T13:15:55Z"}
{"level":"info","msg":"batch size: 1 mtu:1280","time":"2024-12-13T13:15:55Z"}
{"error":"failed to read IPv6 header: EOF","level":"error","msg":"failed to forward data to tunnel interface","time":"2024-12-13T13:17:17Z"}
{"error":"could not write packet. write tcp 127.0.0.1:54935-\u003e127.0.0.1:27015: wsasend: An established connection was aborted by the software in your host machine.","level":"error","msg":"failed to forward data to the device","time":"2024-12-13T13:17:18Z"}

[karthikgbbristol]

After doing some experiments he following sequence works.

1)Start tunnel using ios.exe tunnel start --userspace
2)Disconnect device
3)Kill and start tunnel using same command
4)Now able to connect

I think upon disconnection a new tunnel needs to be created (ater stopping the old one).

Is there a way to do this without killing ios.exe?

[hanyaping]

Hello,

I’m using your go-ios library and have deployed it on Ubuntu. My main goal is to modify the GPS location of an iPhone on the same local network without using a cable. Does the go-ios library support this? Can it help me achieve the functionality I need?

Thank you in advance, and I’d appreciate it if you could reply.

Best regards,
Han YaPing

[danielpaulus]

Keeping this open as the canonical Wi-Fi tunnel persistence issue (it also absorbs the Wi-Fi half of #596 and #262). What's needed: tunnel liveness detection so dead tunnels are evicted and recreated — PR #809 adds that probe as the first half — plus actual tunnel establishment over Wi-Fi, which go-ios doesn't do yet (network-only devices are currently skipped by the TunnelManager), plus a Wi-Fi-reachable farm device to validate against (#749 tracks the transport groundwork). So no, the tunnel can't be forced to survive a cable pull today; your restart sequence is the correct workaround, and with #809 the agent will recreate the tunnel automatically on reconnect instead of you killing ios.exe. @hanyaping: same answer for your case — setlocation on iOS 17+ needs the tunnel, which currently requires USB.