Skip to content

IPFilter overlapping IP ranges not handled — acknowledged correctness gap

Summary

srchybrid/IPFilter.cpp contains two comments explicitly acknowledging that overlapping IP filter entries are not handled:

// IPFilter.cpp:229
// overlapping entries are not yet handled

// IPFilter.cpp:396
// overlapping entries are not yet handled

When two filter rules overlap (e.g. 192.168.1.0/24 and 192.168.1.128/25), the current lookup may return inconsistent results depending on insertion order.

Impact

  • IP filter lists imported from third-party sources (e.g. blocklist.org) routinely contain overlapping ranges.
  • A peer that should be blocked may be let through if it falls in an overlap zone where the more-specific rule is shadowed by the less-specific one.
  • Conversely, a legitimate peer may be blocked by a broad overlapping rule when a narrower allow-rule exists.

Fix

Implement one of: 1. Sorted merge on import — normalise and merge overlapping ranges at import time so the stored table has no overlaps. 2. Longest-prefix-match lookup — when looking up an IP, find the most-specific matching range rather than the first. 3. Deduplication pass — run a cleanup pass after loading that removes or merges any overlapping entries, logging a warning for each.

2026-04-26 Cross-Variant Update

The current eMuleAI tree is useful as an IP-filter input-policy reference, but it does not close this overlap correctness item:

  • eMuleAI adds PeerGuardian *.p2p parsing, static filter overlays, whitelist inputs, and private-IP exemption handling.
  • Those behaviors are now tracked separately as FEAT-044.
  • The comments and semantics around overlapping ranges at different levels still need an explicit merge or lookup policy before this bug can be closed.

FEAT-042 already made automatic update promotion safe on current main. Future IP-filter work should build on that path while keeping this overlap bug as the correctness gate.

Files

  • srchybrid/IPFilter.cpp:229
  • srchybrid/IPFilter.cpp:396
  • srchybrid/IPFilter.h

Resolution

Done in app commit 743b914 and tests commit d0af7be.

IP filter loads now normalize the parsed range table into sorted, non-overlapping segments before the existing binary-search lookup path sees it. When ranges overlap, the lowest numeric filter level wins for the overlapped segment, matching the existing duplicate-range behavior. Adjacent segments with the same effective level are merged, while adjacent different-level segments remain distinct. This closes the correctness gap without adding whitelist or private-IP policy, which remains tracked separately under FEAT-044.