fix: high cpu when iface remove

[akkuman]

related #1669

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: d9f9c5a2-1093-4c0a-b0e5-8635e648777a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[neo-by-projectdiscovery-dev]

Neo - PR Security Review

No security issues found

_{Comment @pdneo help for available commands. · Open in Neo}

[Mzack9999]

Thanks for the fix! The PacketSource approach is cleaner and does resolve the immediate CPU spinning issue by leveraging gopacket v1.2.0's internal 5ms sleep on errors.

However, there are two concerns with the current approach:

1. Goroutine leak on interface removal: pcap.NextErrorReadError doesn't match any of gopacket's known unrecoverable errors, so packetsToChannel will never break — it will sleep-and-retry indefinitely. The CPU spike is fixed, but the goroutine silently lingers for the lifetime of the process.

2. No cancellation support: Packets() uses context.Background() internally, so there's no way to stop the read loop on shutdown. gopacket v1.2.0 provides PacketsCtx(ctx) — wiring that to a cancellable context (e.g., from the scanner lifecycle) would allow clean termination.

Suggested change: use PacketsCtx(ctx) instead of Packets(), where ctx is derived from the scanner's shutdown signal. This would fix both the goroutine leak and enable graceful cleanup:

packetSource := gopacket.NewPacketSource(handler, handler.LinkType())
for packet := range packetSource.PacketsCtx(ctx) {
    data := packet.Data()
    // ...
}

This way, when the scanner shuts down (or the interface is known to be gone), cancelling the context will cleanly terminate the read loop.

[akkuman]

Thank you for reviewing, I will make corrections.

[akkuman]

@Mzack9999 I have carefully reviewed the two issues you mentioned, and I have found that they cannot be resolved:

1. When pcap.NextErrorReadError is thrown, it's not actually possible to determine whether the problem is caused by the disappearance of the virtual network interface or by some other reason for the read error. Therefore, the official implementation of gopacket reflects the expected behavior and is not a goroutine leak.
2. This function was originally designed to execute throughout the entire program lifecycle, so no context was passed in to the outer function, making it impossible to call PacketsCtx(ctx).