[Bug] Internet-Check returns 0.0.0.0 when IPv6 is enabled and OpenDNS lookup fails

フォールバックは server/plugins/internet_ip/script.py の fallback_check_ip() にあり、curl を呼び出して、IPv4 専用の正規表現で結果を検証しています。その関数とレポート内の INTRNT 設定を読み、IPv6 のみのフォールバック応答でプラグインを実行して 0.0.0.0 という結果を再現してください。フォールバックがタイムアウト付きの HTTPS で IPv4 を要求し、IPv6 の応答が 0.0.0.0 として記録されなくなれば完了です。

What installation are you running?

Production (netalertx) 📦

Is there an existing issue for this?

• I have searched the existing open and closed issues and I checked the docs https://docs.netalertx.com/

The issue occurs in the following browsers. Select at least 2.

• Firefox
• Chrome
• Edge
• Safari (unsupported) - PRs welcome
• N/A - This is an issue with the backend

Current Behavior

The built-in Internet-Check (INTRNT) plugin records 0.0.0.0 as the public internet IP when its primary OpenDNS lookup fails on a dual-stack IPv4/IPv6 network. Its curl fallback receives a valid public IPv6 address, rejects it with IPv4-only validation, and returns 0.0.0.0 despite working internet connectivity.

The observed run completes in approximately two seconds and reports SUCCESS, but the detected address remains 0.0.0.0.

Environment

• Ubuntu 24.04 LTS
• Docker Compose, host networking
• Production image: ghcr.io/netalertx/netalertx
• Image digest: sha256:0ee5cdcaa8a84bfd2f31354b4b30e603804d124821055b9942dcffb52d2ce4bc
• dig version: 9.20.26
• Working IPv4 and IPv6 connectivity
• Local DNS resolver; direct external DNS queries restricted

Independent verification

This command was run inside the same NetAlertX container and successfully returned the correct public IPv4 address:

curl -4 -sS --connect-timeout 3 --max-time 8 https://ifconfig.me/ip

Normal DNS resolution through the local resolver also works. Public IP addresses are redacted from this report.

Cause identified

In server/plugins/internet_ip/script.py, fallback_check_ip() invokes:

subprocess.check_output(['curl', '-s', 'ifconfig.me/ip'], text=True).strip()

It then checks the response against an IPv4-only regular expression. The request does not force IPv4, specify HTTPS, or set request timeouts. When the service returns IPv6, the fallback rejects the response.

Related: https://github.com/netalertx/NetAlertX/issues/667 concerns OpenDNS timeouts; this report specifically concerns the fallback rejecting an IPv6 response.

Expected Behavior

Internet-Check should correctly retrieve the public IPv4 address when the primary OpenDNS lookup is unavailable and IPv4 internet connectivity is working. An IPv6 response from the fallback service should not cause a false 0.0.0.0 result. Ideally, IP lookup failures should be distinguished from confirmed internet outages.

Proposed upstream fix

Explicitly request IPv4 over HTTPS and bound connection and execution time:

subprocess.check_output(
    [
        'curl', '-4', '-fsS',
        '--connect-timeout', '3',
        '--max-time', '8',
        'https://ifconfig.me/ip'
    ],
    text=True
).strip()

The IPv4-over-HTTPS command shown in Current Behavior was tested successfully in the affected container; the proposed Python change has not been installed or tested as a complete plugin fix. Consider validating the result with ipaddress.IPv4Address as well.

Please incorporate the correction into the official image so it survives normal updates without maintaining a modified script inside the container.

Steps To Reproduce

1. Run NetAlertX on a dual-stack network with working IPv4 and IPv6 connectivity.
2. Use the OpenDNS public-IP lookup and the INTRNT settings below. The reduced DNS timeout/retries allow the fallback to run within the overall plugin timeout.
3. Reproduce in an environment where direct DNS requests to OpenDNS do not succeed, while normal local DNS and outbound internet access remain available.
4. Run Internet-Check and observe the curl fallback return a valid public IPv6 address.
5. Observe 'Invalid IP received from fallback' and a recorded address of 0.0.0.0, although the plugin reports SUCCESS.
6. Run the curl -4 HTTPS verification command inside the same container and observe that it returns the correct public IPv4 address.

Relevant app.conf settings

INTRNT_DIG_GET_IP_ARG='-4 myip.opendns.com @resolver1.opendns.com +time=1 +tries=1'
INTRNT_RUN_TIMEOUT=30
INTRNT_RETRIES=0

docker-compose.yml

# Relevant excerpt from the existing Compose configuration.
# Incomplete excerpt: other deployment settings and volume definitions omitted.
services:
  netalertx:
    container_name: netalertx
    image: ghcr.io/netalertx/netalertx@sha256:0ee5cdcaa8a84bfd2f31354b4b30e603804d124821055b9942dcffb52d2ce4bc
    network_mode: host
    restart: unless-stopped

Debug or Trace enabled

• I have read and followed the steps in the wiki link above and provided the required debug logs and the log section covers the time when the issue occurs.

Relevant app.log section

Relevant captured INTRNT execution; the public IPv6 address is redacted. The configured LOG_LEVEL at capture time has not been confirmed.

20:31:06 [INTRNT] In script
20:31:06 [INTRNT] INTRNT_DIG_GET_IP_ARG: -4 myip.opendns.com @resolver1.opendns.com +time=1 +tries=1
20:31:06 [INTRNT] - Retrieving internet IP
20:31:07 [INTRNT] Current internet_IP : 0.0.0.0
20:31:07 [INTRNT] previous_IP : 0.0.0.0
20:31:08 [INTRNT] Invalid IP received from fallback
20:31:08 [INTRNT] Curl Fallback (new_internet_IP|cmd_output): 0.0.0.0 | Fallback via curl failed: "<valid public IPv6 address>"
20:31:08 [INTRNT] Finished
20:31:08 [Plugins] SUCCESS for INTRNT received 1 entries

Docker Logs

Separate Docker stdout/stderr logs were not included in the captured diagnostic record. The relevant INTRNT execution output is provided in the app.log section above. This field does not represent output from docker logs.