[Bug] Internet-Check returns 0.0.0.0 when IPv6 is enabled and OpenDNS lookup fails
Maintainers usually reply within 1 day
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
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
- Run NetAlertX on a dual-stack network with working IPv4 and IPv6 connectivity.
- 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.
- Reproduce in an environment where direct DNS requests to OpenDNS do not succeed, while normal local DNS and outbound internet access remain available.
- Run Internet-Check and observe the curl fallback return a valid public IPv6 address.
- Observe 'Invalid IP received from fallback' and a recorded address of 0.0.0.0, although the plugin reports SUCCESS.
- 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
Starts the project's dev container in your browser, under your own GitHub account.
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from netalertx/NetAlertX
-
bug 🐛
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
netalertx/NetAlertX#1856 · 1 comment · 7 reactions ·
Maintainers usually reply within 1 day
-
[Bug] MCP SSE endpoint event omits the /server prefix, so clients behind the built-in nginx proxy get a 404 on /mcp/messagesPossibly taken @frdmn claimed this 1 day ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Docker 🐋
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
bug 🐛 next release/in dev image 🚀 Waiting for reply⏳
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
netalertx/NetAlertX#1851 · 2 comments ·
Maintainers usually reply within 1 day
-
bug 🐛 next release/in dev image 🚀
Difficulty 2/5 1-3 hours Newbie friendliness 63/100
netalertx/NetAlertX#1841 · 3 comments ·
Maintainers usually reply within 1 day
All issues in netalertx/NetAlertX
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
khuisman/mcp-gee-sweet#1166 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
lugassawan/swe-workbench#823 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
gramaziokohler/compas_timber#870 ·
-
security-scan-failure
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
semantica-agi/semantica#2089 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
autowarefoundation/autoware_carla_scenario#500 ·
Maintainers usually reply within 1 day