feat: Add mDNS support for network discovery and dynamic hostname updates #1240

camalolo · 2025-09-18T05:27:14Z

Pull Request: Add mDNS Support for Network Discovery and Dynamic Hostname Updates

Summary

This PR implements comprehensive mDNS (Multicast DNS) support for the ESP-Miner device, enabling seamless network discovery and dynamic hostname management. The implementation allows devices to be discovered automatically on local networks using Bonjour/Avahi-compatible services.

Key Features Added

🔍 Network Discovery

mDNS Service Registration: Device automatically registers as "ESP-Miner Web Server" with HTTP service on port 80
Bonjour/Avahi Compatibility: Device is discoverable using standard network discovery tools
Zero-Configuration Networking: No manual IP address configuration needed for local access

🌐 Dynamic Hostname Management

Automatic mDNS Hostname Setup: Hostname is set during WiFi initialization
Dynamic Updates: Hostname changes are reflected in mDNS immediately when updated via web interface
Hostname Normalization: Prevents duplicate ".local.local" suffixes by stripping existing ".local" before setting

🛡️ Enhanced Security & Usability

Simplified CORS Logic: Streamlined network access validation for private IP ranges
Graceful Degradation: mDNS failures don't prevent device operation, only log warnings
Comprehensive Logging: Detailed status messages for troubleshooting

Technical Implementation

Files Modified:

components/connect/CMakeLists.txt - Added mDNS component dependency
components/connect/connect.c - Core mDNS initialization and management
components/connect/include/connect.h - Public API for hostname updates
main/http_server/http_server.c - Dynamic hostname updates and CORS improvements
main/idf_component.yml - Added espressif/mdns dependency

Key Functions Added:

mdns_init() - Initializes mDNS service
mdns_hostname_set() - Sets device hostname for discovery
mdns_service_add() - Registers HTTP service
update_mdns_hostname() - Dynamic hostname updates
normalize_hostname() - Prevents hostname conflicts

Usage Examples

Network Discovery:

# Discover device using avahi-browse
avahi-browse _http._tcp

# Access via mDNS hostname
curl http://esp-miner-XXXX.local

Web Interface Updates:

Hostname changes in the web UI now immediately update mDNS
Device remains discoverable with new hostname without restart

Benefits

✅ Improved User Experience: No need to remember IP addresses
✅ Network-Friendly: Works with existing Bonjour/Avahi infrastructure
✅ Dynamic Configuration: Hostname changes take effect immediately
✅ Backward Compatible: Existing functionality remains unchanged
✅ Robust Error Handling: Graceful degradation on mDNS failures

Testing Considerations

Verify device appears in network discovery tools (avahi-browse, Bonjour Browser)
Test hostname updates via web interface
Confirm HTTP access works via .local hostname
Test behavior when mDNS initialization fails
Validate CORS still works for private network access

Dependencies Added

espressif/mdns: ^1.8.0 - Official ESP-IDF mDNS component

This implementation provides a solid foundation for network discovery and makes the ESP-Miner much more user-friendly in home and enterprise networks.

main/http_server/http_server.c

github-actions · 2025-09-18T08:30:11Z

Test Results

20 tests ±0 20 ✅ ±0 0s ⏱️ ±0s
1 suites ±0 0 💤 ±0
1 files ±0 0 ❌ ±0

Results for commit e5999d4. ± Comparison against base commit d954c4f.

♻️ This comment has been updated with latest results.

mutatrum · 2025-09-18T09:00:57Z

One other thing to consider if the swarm screen is working with mDNS hostnames.

camalolo · 2025-09-18T15:33:27Z

Regarding http_server.c and CORS : I believe I restored the original checks, while adding a block that also allows requests with Origin set to the mDNS host.

.github/workflows/unittest.yml

mutatrum · 2025-09-18T21:05:53Z

This was also part of #1133, but it's good it's a separate API. Code looks good but haven't tested it yet, I'll give it a spin tomorrow.

camalolo · 2025-09-20T06:25:24Z

One other thing to consider if the swarm screen is working with mDNS hostnames.

Preliminary work shows it does not. Other bitaxes with no support for mDNS hostnames reject the requests to /api/system/info as they violate CORS when sent from a swarm page that runs on a domain such as http://bitaxe.local. So far the best idea that might work could be to proxy the requests thru the backend of the current device, but I have concerns of an automatic scan for hundreds of hosts thru the backend.

mutatrum · 2025-09-20T09:39:03Z

One other thing to consider if the swarm screen is working with mDNS hostnames.

Preliminary work shows it does not. Other bitaxes with no support for mDNS hostnames reject the requests to /api/system/info as they violate CORS when sent from a swarm page that runs on a domain such as http://bitaxe.local. So far the best idea that might work could be to proxy the requests thru the backend of the current device, but I have concerns of an automatic scan for hundreds of hosts thru the backend.

No, swarm should stay front-end.

So is this correct?

swarm device	client device	result
ip	ip	works
ip	hostname	works
hostname	ip	CORS
hostname	hostname	works

If this is the case, then I guess it's fine for now? Does mean that NerdAxes need this at some point as well.

Unfortunately I only have a single device at the moment, so I can't test this.

camalolo · 2025-09-20T10:06:39Z

One other thing to consider if the swarm screen is working with mDNS hostnames.

Preliminary work shows it does not. Other bitaxes with no support for mDNS hostnames reject the requests to /api/system/info as they violate CORS when sent from a swarm page that runs on a domain such as http://bitaxe.local. So far the best idea that might work could be to proxy the requests thru the backend of the current device, but I have concerns of an automatic scan for hundreds of hosts thru the backend.

No, swarm should stay front-end.

So is this correct?

swarm device client device result
ip ip works
ip hostname works
hostname ip CORS
hostname hostname works
If this is the case, then I guess it's fine for now? Does mean that NerdAxes need this at some point as well.

Unfortunately I only have a single device at the moment, so I can't test this.

I'll try again implementing it on the swarm page, maybe my first attempt was incorrect.

The swarm page accessible at http://bitaxe.local/#/swarm would try to connect to for example http://192.168.1.10/api/system/info, but because the Origin header is http://bitaxe.local/, the device at 192.168.1.10 replied with a 401 (because it runs a firmware without mDNS support, so it did not understand the bitaxe.local Origin header).

If you think that shouldn't be an issue, then I'll try again to implement it and give feedback if I succeed.

camalolo · 2025-09-20T11:43:13Z

One other thing to consider if the swarm screen is working with mDNS hostnames.

Preliminary work shows it does not. Other bitaxes with no support for mDNS hostnames reject the requests to /api/system/info as they violate CORS when sent from a swarm page that runs on a domain such as http://bitaxe.local. So far the best idea that might work could be to proxy the requests thru the backend of the current device, but I have concerns of an automatic scan for hundreds of hosts thru the backend.

No, swarm should stay front-end.
So is this correct?
swarm device client device result
ip ip works
ip hostname works
hostname ip CORS
hostname hostname works
If this is the case, then I guess it's fine for now? Does mean that NerdAxes need this at some point as well.
Unfortunately I only have a single device at the moment, so I can't test this.

I'll try again implementing it on the swarm page, maybe my first attempt was incorrect.

The swarm page accessible at http://bitaxe.local/#/swarm would try to connect to for example http://192.168.1.10/api/system/info, but because the Origin header is http://bitaxe.local/, the device at 192.168.1.10 replied with a 401 (because it runs a firmware without mDNS support, so it did not understand the bitaxe.local Origin header).

If you think that shouldn't be an issue, then I'll try again to implement it and give feedback if I succeed.

Got the same issue after starting from scratch. Basically, if the other bitaxe(s) on the LAN don't have the mDNS patch, they cannot be accessed because of the URL on the bitaxe you are viewing the swarm page on.

The Specific Issue

Your current page: Served from http://espressif.local
Target device: http://192.168.1.114
Browser security: Blocks the XMLHttpRequest because espressif.local ≠ 192.168.1.114
Chrome console shows: Access to XMLHttpRequest at 'http://192.168.1.114/api/system/info' from origin 'http://espressif.local' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Why It Happens

The browser sends a preflight OPTIONS request to 192.168.1.114
The ESP device responds without CORS headers
Browser blocks the actual request and shows: "No 'Access-Control-Allow-Origin' header is present"

The Root Cause

The ESP device firmware doesn't include the required CORS response headers:

Access-Control-Allow-Origin
Access-Control-Allow-Methods
Access-Control-Allow-Headers

This is a server-side issue where the older ESP device is not able to allow cross-origin requests from your web interface

So basically : using the mDNS feature and accessing the swarm page via the nice URL breaks the swarm page as it cannot connect to "older" bitaxes. That might be a problem until those devices receive a firmware upgrade.

Maybe you know a better way ?

mutatrum · 2025-09-20T12:22:32Z

Thanks for the extensive write-up. I think it's fine, we can't expect older devices to magically do-the-right-thing ™️ . For single users, this is a nice improvement as there's a lot of people who run into issues if their local setup already works for hostnames, but none of the calls (f.e. firmware updates) work. For swarm users, they can start using it whenever they have upgraded their devices.

mutatrum · 2025-09-20T12:27:35Z

One addition (don't know if that's not already the case): if a mDNS device scans and find a Bitaxe device which also has mDNS, to query it on it's hostname instead of IP. Basically, at some point, we could get rid of the ip column in swarm, or migrate them to a single column.

camalolo · 2025-09-21T05:28:50Z

Swarm Enhancement: Support for IPs and mDNS Hostnames
I've pushed a commit that updates the swarm management page to handle both IP addresses and mDNS hostnames (e.g., bitaxe.local). Here's what changed:

Frontend Changes (Angular):

Renamed all "IP" references to "address" for better clarity and flexibility.
Updated the manual add form to accept hostnames with validation (supports .local domains).
Enhanced sorting logic: IPs sort numerically, hostnames alphabetically, with IPs prioritized.
Added user-friendly error handling for older devices that may not be compatible.

Backend Changes :

Added the device's current IP address to the /api/system/info JSON response to enable subnet scanning when accessing via hostname. Required to be able to scan the LAN as the browser does not seem to be able to resolve the IP of the current page when accessing it over a .local domain

Key Benefits:

Users can now add swarm peers using either IP (e.g., 192.168.1.100) or hostname (e.g., bitaxe.local).
Network scanning works seamlessly regardless of access method.
Backward compatible with existing IP-based setups.

The build passes successfully, and all changes maintain existing functionality while expanding support. Ready for review and testing!

camalolo · 2025-09-21T05:30:03Z

NB I wrote "backwards compatible" but in fact it's not really correct - older firmware block calling their API from a mDNS domain because of CORS

…ates

…ve device discovery

mutatrum · 2025-09-21T15:06:28Z

components/connect/connect.c

+            }
+
+            /* Set mDNS instance name */
+            err = mdns_instance_name_set("ESP-Miner Web Server");


Is this instance name exposed somewhere, or is it internal only? If exposed, maybe we can give it a bit nicer name. Maybe device model, f.e. Bitaxe Gamma from DeviceConfig?

mutatrum · 2025-09-21T15:25:53Z

Testing it now. Opening swarm gave a ton of these messages:

I think that's not ok. It found itself, but had it's IP as address, not sure if that's desired:

It popped up in avahi-browse after boot, which is nice:

mutatrum@laptop:~$ avahi-browse _http._tcp
+ enx5c857e30fd32 IPv4 ESP32 WebServer                               Web Site             local

But would indeed make the description reflect the device.

mutatrum · 2025-09-21T15:33:28Z

Changing settings while accessing it on hostname works, but it gave a log line:

W (331374) CORS: Invalid IP address: bitaxe-gamma

I didn't access with hostname.local, just hostname. Not sure what happened after that, i tried accessing on hostname.localhost, and that crashed the device. On restart, the watchdog was triggered:

I (6524) connect: IP Address: 192.168.1.20
I (6524) connect: Connected to SSID: *****
I (6525) wifi:mode : sta (d8:3b:da:6e:cd:cc)
I (6529) esp_netif_handlers: sta ip: 192.168.1.20, mask: 255.255.255.0, gw: 192.168.1.1
I (6536) connect: Configuration Access Point disabled
E (7448) task_wdt: Task watchdog got triggered. The following tasks/users did not reset the watchdog in time:
E (7448) task_wdt:  - IDLE0 (CPU 0)
E (7448) task_wdt: Tasks currently running:
E (7448) task_wdt: CPU 0: main
E (7448) task_wdt: CPU 1: IDLE1
E (7448) task_wdt: Print CPU 0 (current core) backtrace


Backtrace: 0x42052DB3:0x3FC9EEF0 0x40377309:0x3FC9EF20 0x4202C531:0x3FCC0060 0x42027D82:0x3FCC00A0 0x42027DCD:0x3FCC00D0 0x4203B64E:0x3FCC0100 0x4203B689:0x3FCC01C0 0x420DAEC5:0x3FCC02B0 0x42027450:0x3FCC02D0 0x4202A37A:0x3FCC0320 0x4202AB25:0x3FCC0360 0x4202B2CA:0x3FCC0390 0x420278AB:0x3FCC03C0 0x42027987:0x3FCC03F0 0x42019A78:0x3FCC0410 0x4200E769:0x3FCC0430 0x4200E347:0x3FCC0460 0x420E65EF:0x3FCC0490
--- 0x42052db3: task_wdt_timeout_handling at /home/mutatrum/esp/v5.5.1/esp-idf/components/esp_system/task_wdt/task_wdt.c:436
--- (inlined by) task_wdt_isr at /home/mutatrum/esp/v5.5.1/esp-idf/components/esp_system/task_wdt/task_wdt.c:509
--- 0x40377309: _xt_lowint1 at /home/mutatrum/esp/v5.5.1/esp-idf/components/xtensa/xtensa_vectors.S:1240
--- 0x4202c531: lv_inv_area at /home/mutatrum/code-workspace/esp-miner/managed_components/lvgl__lvgl/src/core/lv_refr.c:277
--- 0x42027d82: lv_obj_invalidate_area at /home/mutatrum/code-workspace/esp-miner/managed_components/lvgl__lvgl/src/core/lv_obj_pos.c:847
--- 0x42027dcd: lv_obj_invalidate_area at /home/mutatrum/code-workspace/esp-miner/managed_components/lvgl__lvgl/src/core/lv_obj_pos.c:824
--- (inlined by) lv_obj_invalidate at /home/mutatrum/code-workspace/esp-miner/managed_components/lvgl__lvgl/src/core/lv_obj_pos.c:863

I'll flash back to master, to see if it's something on my network. I'll test further this evening.

Addition: reflashed master and device boots again. Not sure what was happening here. Will continue.

camalolo · 2025-09-21T15:42:24Z

Thanks for the feedback.

Yeah I also was hesitating about the "potential peer" warnings. It's an issue with CORS and XHR, on my LAN I have a bunch of devices that can be reached (TVs, routers, etc), but the swarm page cannot really get accurate HTTP status (like a 404 for most devices, or 401 for older bitaxes). Initially I wanted to warn the user they should update the firmware on the other bitaxe(s) but it would make sense they upgrade all of the devices more or less at the same time anyways. I think I can silently skip unresponsive devices without warning.

Agree with you about the mDNS instance name, using the device model is a good idea, will implement.

I will also try to play around with editing the hostname, to see if I can get the same crash as you did. Could it be the length of the hostname, or the "-" ?

mutatrum · 2025-09-21T20:32:11Z

Note on the crash: I had avahi-browse _http._tcp running at that moment, not sure if that has anything to do with it?

camalolo · 2025-09-22T02:16:03Z

I (6524) connect: IP Address: 192.168.1.20
I (6524) connect: Connected to SSID: *****
I (6525) wifi:mode : sta (d8:3b:da:6e:cd:cc)
I (6529) esp_netif_handlers: sta ip: 192.168.1.20, mask: 255.255.255.0, gw: 192.168.1.1
I (6536) connect: Configuration Access Point disabled
E (7448) task_wdt: Task watchdog got triggered. The following tasks/users did not reset the watchdog in time:
E (7448) task_wdt: - IDLE0 (CPU 0)
E (7448) task_wdt: Tasks currently running:
E (7448) task_wdt: CPU 0: main
E (7448) task_wdt: CPU 1: IDLE1
E (7448) task_wdt: Print CPU 0 (current core) backtrace

Backtrace: 0x42052DB3:0x3FC9EEF0 0x40377309:0x3FC9EF20 0x4202C531:0x3FCC0060 0x42027D82:0x3FCC00A0 0x42027DCD:0x3FCC00D0 0x4203B64E:0x3FCC0100 0x4203B689:0x3FCC01C0 0x420DAEC5:0x3FCC02B0 0x42027450:0x3FCC02D0 0x4202A37A:0x3FCC0320 0x4202AB25:0x3FCC0360 0x4202B2CA:0x3FCC0390 0x420278AB:0x3FCC03C0 0x42027987:0x3FCC03F0 0x42019A78:0x3FCC0410 0x4200E769:0x3FCC0430 0x4200E347:0x3FCC0460 0x420E65EF:0x3FCC0490
--- 0x42052db3: task_wdt_timeout_handling at /home/mutatrum/esp/v5.5.1/esp-idf/components/esp_system/task_wdt/task_wdt.c:436
--- (inlined by) task_wdt_isr at /home/mutatrum/esp/v5.5.1/esp-idf/components/esp_system/task_wdt/task_wdt.c:509
--- 0x40377309: _xt_lowint1 at /home/mutatrum/esp/v5.5.1/esp-idf/components/xtensa/xtensa_vectors.S:1240
--- 0x4202c531: lv_inv_area at /home/mutatrum/code-workspace/esp-miner/managed_components/lvgl__lvgl/src/core/lv_refr.c:277
--- 0x42027d82: lv_obj_invalidate_area at /home/mutatrum/code-workspace/esp-miner/managed_components/lvgl__lvgl/src/core/lv_obj_pos.c:847
--- 0x42027dcd: lv_obj_invalidate_area at /home/mutatrum/code-workspace/esp-miner/managed_components/lvgl__lvgl/src/core/lv_obj_pos.c:824
--- (inlined by) lv_obj_invalidate at /home/mutatrum/code-workspace/esp-miner/managed_components/lvgl__lvgl/src/core/lv_obj_pos.c:863

Based on the backtrace of the crash, it seems to be related to the screen animation, not the network. But please don't take my word for it, I am not super familiar with any of the code to be honest, and that part is definitely above my head :)

camalolo · 2025-09-22T02:20:47Z

I (6524) connect: IP Address: 192.168.1.20
I (6524) connect: Connected to SSID: *****
I (6525) wifi:mode : sta (d8:3b:da:6e:cd:cc)
I (6529) esp_netif_handlers: sta ip: 192.168.1.20, mask: 255.255.255.0, gw: 192.168.1.1
I (6536) connect: Configuration Access Point disabled
E (7448) task_wdt: Task watchdog got triggered. The following tasks/users did not reset the watchdog in time:
E (7448) task_wdt: - IDLE0 (CPU 0)
E (7448) task_wdt: Tasks currently running:
E (7448) task_wdt: CPU 0: main
E (7448) task_wdt: CPU 1: IDLE1
E (7448) task_wdt: Print CPU 0 (current core) backtrace
Backtrace: 0x42052DB3:0x3FC9EEF0 0x40377309:0x3FC9EF20 0x4202C531:0x3FCC0060 0x42027D82:0x3FCC00A0 0x42027DCD:0x3FCC00D0 0x4203B64E:0x3FCC0100 0x4203B689:0x3FCC01C0 0x420DAEC5:0x3FCC02B0 0x42027450:0x3FCC02D0 0x4202A37A:0x3FCC0320 0x4202AB25:0x3FCC0360 0x4202B2CA:0x3FCC0390 0x420278AB:0x3FCC03C0 0x42027987:0x3FCC03F0 0x42019A78:0x3FCC0410 0x4200E769:0x3FCC0430 0x4200E347:0x3FCC0460 0x420E65EF:0x3FCC0490
--- 0x42052db3: task_wdt_timeout_handling at /home/mutatrum/esp/v5.5.1/esp-idf/components/esp_system/task_wdt/task_wdt.c:436
--- (inlined by) task_wdt_isr at /home/mutatrum/esp/v5.5.1/esp-idf/components/esp_system/task_wdt/task_wdt.c:509
--- 0x40377309: _xt_lowint1 at /home/mutatrum/esp/v5.5.1/esp-idf/components/xtensa/xtensa_vectors.S:1240
--- 0x4202c531: lv_inv_area at /home/mutatrum/code-workspace/esp-miner/managed_components/lvgl__lvgl/src/core/lv_refr.c:277
--- 0x42027d82: lv_obj_invalidate_area at /home/mutatrum/code-workspace/esp-miner/managed_components/lvgl__lvgl/src/core/lv_obj_pos.c:847
--- 0x42027dcd: lv_obj_invalidate_area at /home/mutatrum/code-workspace/esp-miner/managed_components/lvgl__lvgl/src/core/lv_obj_pos.c:824
--- (inlined by) lv_obj_invalidate at /home/mutatrum/code-workspace/esp-miner/managed_components/lvgl__lvgl/src/core/lv_obj_pos.c:863

Based on the backtrace of the crash, it seems to be related to the screen animation, not the network. But please don't take my word for it, I am not super familiar with any of the code to be honest, and that part is definitely above my head :)

One possibility : the mDNS feature somehow freezes the CPU long enough for the display code to fail. Maybe I should make sure the mDNS code runs a bit later after boot and/or asynchronously

camalolo · 2025-09-22T02:24:54Z

I (6524) connect: IP Address: 192.168.1.20
I (6524) connect: Connected to SSID: *****
I (6525) wifi:mode : sta (d8:3b:da:6e:cd:cc)
I (6529) esp_netif_handlers: sta ip: 192.168.1.20, mask: 255.255.255.0, gw: 192.168.1.1
I (6536) connect: Configuration Access Point disabled
E (7448) task_wdt: Task watchdog got triggered. The following tasks/users did not reset the watchdog in time:
E (7448) task_wdt: - IDLE0 (CPU 0)
E (7448) task_wdt: Tasks currently running:
E (7448) task_wdt: CPU 0: main
E (7448) task_wdt: CPU 1: IDLE1
E (7448) task_wdt: Print CPU 0 (current core) backtrace
Backtrace: 0x42052DB3:0x3FC9EEF0 0x40377309:0x3FC9EF20 0x4202C531:0x3FCC0060 0x42027D82:0x3FCC00A0 0x42027DCD:0x3FCC00D0 0x4203B64E:0x3FCC0100 0x4203B689:0x3FCC01C0 0x420DAEC5:0x3FCC02B0 0x42027450:0x3FCC02D0 0x4202A37A:0x3FCC0320 0x4202AB25:0x3FCC0360 0x4202B2CA:0x3FCC0390 0x420278AB:0x3FCC03C0 0x42027987:0x3FCC03F0 0x42019A78:0x3FCC0410 0x4200E769:0x3FCC0430 0x4200E347:0x3FCC0460 0x420E65EF:0x3FCC0490
--- 0x42052db3: task_wdt_timeout_handling at /home/mutatrum/esp/v5.5.1/esp-idf/components/esp_system/task_wdt/task_wdt.c:436
--- (inlined by) task_wdt_isr at /home/mutatrum/esp/v5.5.1/esp-idf/components/esp_system/task_wdt/task_wdt.c:509
--- 0x40377309: _xt_lowint1 at /home/mutatrum/esp/v5.5.1/esp-idf/components/xtensa/xtensa_vectors.S:1240
--- 0x4202c531: lv_inv_area at /home/mutatrum/code-workspace/esp-miner/managed_components/lvgl__lvgl/src/core/lv_refr.c:277
--- 0x42027d82: lv_obj_invalidate_area at /home/mutatrum/code-workspace/esp-miner/managed_components/lvgl__lvgl/src/core/lv_obj_pos.c:847
--- 0x42027dcd: lv_obj_invalidate_area at /home/mutatrum/code-workspace/esp-miner/managed_components/lvgl__lvgl/src/core/lv_obj_pos.c:824
--- (inlined by) lv_obj_invalidate at /home/mutatrum/code-workspace/esp-miner/managed_components/lvgl__lvgl/src/core/lv_obj_pos.c:863

Based on the backtrace of the crash, it seems to be related to the screen animation, not the network. But please don't take my word for it, I am not super familiar with any of the code to be honest, and that part is definitely above my head :)

One possibility : the mDNS feature somehow freezes the CPU long enough for the display code to fail. Maybe I should make sure the mDNS code runs a bit later after boot and/or asynchronously

Trying this : moving the mDNS configuration to a later stage in the boot process

…ith better name

camalolo · 2025-09-22T03:02:56Z

Added a new commit :

Moved the mDNS setup after an IP has been received (tentative fix for possible timing issues in display animation)
Made the service show up as Bitaxe (MAC first 4 digits) for easy identification

…lently.

camalolo · 2025-09-22T03:25:55Z

Commit added to the swarm page so it fails silently for irrelevant/old devices during automatic scans

camalolo force-pushed the avahi+devboard branch from 51711c6 to 39e3cef Compare September 18, 2025 07:53

mutatrum reviewed Sep 18, 2025

View reviewed changes

main/http_server/http_server.c Show resolved Hide resolved

camalolo marked this pull request as draft September 18, 2025 08:51

This was linked to issues Sep 18, 2025

Error - while update esp-miner.bin and www.bin - Unauthorized #1118

Open

Add support for mDNS to have pretty dashboard URL #233

Open

camalolo force-pushed the avahi+devboard branch 2 times, most recently from 8f47af4 to 48d33e0 Compare September 18, 2025 15:27

mutatrum reviewed Sep 18, 2025

View reviewed changes

.github/workflows/unittest.yml Show resolved Hide resolved

camalolo force-pushed the avahi+devboard branch from 21f78e5 to a90beaa Compare September 21, 2025 05:25

camalolo force-pushed the avahi+devboard branch from a90beaa to 6ffc023 Compare September 21, 2025 05:34

feat: Add mDNS support for network discovery and dynamic hostname upd…

d0dced6

…ates

camalolo force-pushed the avahi+devboard branch from 6ffc023 to e814a08 Compare September 21, 2025 06:17

feat: Enhance swarm component to support hostname addresses and impro…

e5999d4

…ve device discovery

camalolo force-pushed the avahi+devboard branch from e814a08 to e5999d4 Compare September 21, 2025 07:16

WantClue requested a review from eandersson September 21, 2025 12:40

mutatrum marked this pull request as ready for review September 21, 2025 15:01

mutatrum reviewed Sep 21, 2025

View reviewed changes

Initialize mDNS/Avahi after WiFi connection, advertise HTTP service w…

0a58044

…ith better name

Refactor: Skip processing of swarm peer if system info fetch fails si…

e3f3b5f

…lently.

mutatrum added the enhancement New feature or request label Sep 26, 2025

feat: Add mDNS support for network discovery and dynamic hostname updates #1240

Are you sure you want to change the base?

feat: Add mDNS support for network discovery and dynamic hostname updates #1240

Uh oh!

Conversation

camalolo commented Sep 18, 2025

Pull Request: Add mDNS Support for Network Discovery and Dynamic Hostname Updates

Summary

Key Features Added

🔍 Network Discovery

🌐 Dynamic Hostname Management

🛡️ Enhanced Security & Usability

Technical Implementation

Files Modified:

Key Functions Added:

Usage Examples

Network Discovery:

Web Interface Updates:

Benefits

Testing Considerations

Dependencies Added

Uh oh!

Uh oh!

github-actions bot commented Sep 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results

Uh oh!

mutatrum commented Sep 18, 2025

Uh oh!

camalolo commented Sep 18, 2025

Uh oh!

Uh oh!

mutatrum commented Sep 18, 2025

Uh oh!

camalolo commented Sep 20, 2025

Uh oh!

mutatrum commented Sep 20, 2025

Uh oh!

camalolo commented Sep 20, 2025

Uh oh!

camalolo commented Sep 20, 2025

The Specific Issue

Why It Happens

The Root Cause

Uh oh!

mutatrum commented Sep 20, 2025

Uh oh!

mutatrum commented Sep 20, 2025

Uh oh!

camalolo commented Sep 21, 2025

Uh oh!

camalolo commented Sep 21, 2025

Uh oh!

mutatrum Sep 21, 2025

Choose a reason for hiding this comment

Uh oh!

mutatrum commented Sep 21, 2025

Uh oh!

mutatrum commented Sep 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

camalolo commented Sep 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mutatrum commented Sep 21, 2025

Uh oh!

camalolo commented Sep 22, 2025

Uh oh!

camalolo commented Sep 22, 2025

Uh oh!

camalolo commented Sep 22, 2025

Uh oh!

camalolo commented Sep 22, 2025

Uh oh!

camalolo commented Sep 22, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

github-actions bot commented Sep 18, 2025 •

edited

Loading

mutatrum commented Sep 21, 2025 •

edited

Loading

camalolo commented Sep 21, 2025 •

edited

Loading