Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open Beginner friendly
#1,845 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@pujitha24 is already working on this.

Since Oct 17, 2026.

  • #1846 by @pujitha24 — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
75/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
docker, dockerfile, python
Domain
networking

Research direction

The fallback lives in fallback_check_ip() in server/plugins/internet_ip/script.py, which shells out to curl and checks the result with an IPv4-only regex. Read that function and the INTRNT settings in the report, then run the plugin with an IPv6-only fallback response to reproduce the 0.0.0.0 result. Done when the fallback requests IPv4 over HTTPS with timeouts and an IPv6 response is no longer recorded as 0.0.0.0.

Written by the indexing model from the issue text.

Description

bug 🐛 next release/in dev image 🚀 Waiting for reply⏳
What installation are you running?

Production (netalertx) 📦

Is there an existing issue for this?
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.

Dominant language
Python
Stars
7.2k
Forks
456
Avg merge
17h 59m
Merged PRs (30d)
26

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from netalertx/NetAlertX

All issues in netalertx/NetAlertX

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.