support mipstack

[PharosVip]

No description provided.

[wwqgtxx]

Thank you for your work. I think you could draw inspiration from the work in #26 by @chenx-dust to arrive at an optimal solution.

Additionally, we do not need to add extra build tags for mipstack; we should simply ensure it remains supported at all times.

[PharosVip]

Thank you for your work. I think you could draw inspiration from the work in #26 by @chenx-dust to arrive at an optimal solution.

Additionally, we do not need to add extra build tags for mipstack; we should simply ensure it remains supported at all times.

I’ve incorporated improvements from #26 and removed the with_mipstack build tag

[wwqgtxx]

What I would like to know is whether the contents of this PR have been tested on standard platforms and confirmed to work correctly, or if they were generated solely by AI without verification in an actual working environment. If testing has been performed, I suggest adding detailed test results to the PR description. Thank you.

Additionally, the latest commit to mipstack has eliminated the requirement to configure LocalAddresses when using Promiscuous mode; you might want to update to the latest version to see if the code can be simplified while still functioning correctly.

[PharosVip]

What I would like to know is whether the contents of this PR have been tested on standard platforms and confirmed to work correctly, or if they were generated solely by AI without verification in an actual working environment. If testing has been performed, I suggest adding detailed test results to the PR description. Thank you.

Additionally, the latest commit to mipstack has eliminated the requirement to configure LocalAddresses when using Promiscuous mode; you might want to update to the latest version to see if the code can be simplified while still functioning correctly.

Thank you for the feedback. I’ve tested this PR on iOS, Android, and Windows and confirmed basic connectivity in actual environments. I’ll perform more thorough testing and share the detailed results in a follow-up comment and the PR description.
I’ll also update to the latest mipstack version, simplify the LocalAddresses handling, and retest the changes.

[wwqgtxx]

As a side note, I don't think the changes in the second commit are entirely sound. The forwardICMP section, in particular, appears to boost performance but introduces greater risk. In reality, the ICMPForwarderHandler should return as quickly as possible and avoid any blocking or long-running operations internally; clearly, PrepareConnection offers no guarantee against blocking.

Furthermore, I don't quite understand the addition of s.icmpMu there; DirectRouteMapping is already thread-safe, so what is the purpose of wrapping it in an external lock?

[PharosVip]

As a side note, I don't think the changes in the second commit are entirely sound. The forwardICMP section, in particular, appears to boost performance but introduces greater risk. In reality, the ICMPForwarderHandler should return as quickly as possible and avoid any blocking or long-running operations internally; clearly, PrepareConnection offers no guarantee against blocking.

Furthermore, I don't quite understand the addition of s.icmpMu there; DirectRouteMapping is already thread-safe, so what is the purpose of wrapping it in an external lock?

Thank you for pointing this out. I’ve moved PrepareConnection and packet forwarding to a bounded asynchronous queue.
I’ve also removed s.icmpMu. DirectRouteMapping uses its own synchronization, and the worker handles route cleanup when it exits.
I’ll spend some time conducting additional tests across platforms and share the results.

[wwqgtxx]

I took a look at the current submission. Since the payload has to be copied anyway, you can simply use request.Detach from your previous version; this eliminates the need to manually copy the packet or construct Reset objects yourself.

[PharosVip]

I took a look at the current submission. Since the payload has to be copied anyway, you can simply use request.Detach from your previous version; this eliminates the need to manually copy the packet or construct Reset objects yourself.

I’ve switched to request.Detach() and removed the manual packet copies from the callback. Echo replies and rejections now use responder.ReplyEcho() and responder.Reject(), and the custom Reset construction has been removed.