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

[camalolo]

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:

1. components/connect/CMakeLists.txt - Added mDNS component dependency
2. components/connect/connect.c - Core mDNS initialization and management
3. components/connect/include/connect.h - Public API for hostname updates
4. main/http_server/http_server.c - Dynamic hostname updates and CORS improvements
5. 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.

[github-actions]

Test Results

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

Results for commit 2136515. ± Comparison against base commit a29c654.

♻️ This comment has been updated with latest results.

[mutatrum]

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

[camalolo]

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.

[mutatrum]

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]

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]

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]

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]

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

1. Your current page: Served from http://espressif.local
2. Target device: http://192.168.1.114
3. Browser security: Blocks the XMLHttpRequest because espressif.local ≠ 192.168.1.114
4. 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]

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]

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]

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]

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

[mutatrum]

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]

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]

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]

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]

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]

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]

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]

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

[camalolo]

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

[camalolo]

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

[WantClue]

@camalolo can you please resolve the conflicts ?

[camalolo]

@WantClue hello ! Thanks for bringing this to my attention, I will have a look !

[camalolo]

@WantClue

I updated my branch. Here's a summary of what the commit does :

Core mDNS Implementation

• Added mDNS dependency: Integrated espressif/mdns^1.8.0 component via CMakeLists.txt and CI workflow updates, ensuring reliable network service discovery.
• mDNS initialization: In connect.c, added initialize_mdns() function that:
  • Sets device hostname (e.g., bitaxe.local) for network discovery
  • Registers HTTP service on port 80 with descriptive instance names (e.g., "Bitaxe Ultra 2.1 (ABCD)")
  • Handles IPv4/IPv6 connectivity events to ensure mDNS starts when network is available
  • Includes fallback logging for troubleshooting discovery issues
• Hostname management: Added update_mdns_hostname() for dynamic hostname updates and normalize_hostname() in HTTP server to prevent ".local.local" duplicates.

Swarm Component Refactoring (Address-Based Support)

• Unified address handling: Replaced IP-only logic with flexible "address" support (accepts both IPv4 addresses and .local hostnames)
• Enhanced network scanning:
  • Detects access method (direct IP vs. mDNS hostname) and adapts scanning strategy
  • Fetches server IP via API when accessed via hostname, then scans subnet
  • Improved duplicate detection using hostname/IP cross-checking
• UI updates:
  • Form validation now accepts both IP patterns and .local hostnames
  • Table headers and links updated from "IP" to "Address"
  • Sorting logic enhanced to handle mixed IP/hostname sorting (IPs first, then alphabetical)
• API consistency: All HTTP calls, error handlers, and device references now use address property instead of IP

HTTP Server Enhancements

• CORS improvements: Extended is_network_allowed() to permit requests from mDNS hostnames (e.g., http://bitaxe.local), enabling cross-origin swarm management
• Hostname normalization: Prevents configuration issues by stripping .local suffixes when setting hostnames
  Infrastructure Updates

Others

• Build system: Added mDNS component to connect module dependencies
• CI/CD: Updated unittest workflow to install mDNS dependency for testing
• Documentation: README updated with mDNS discovery instructions

I tested locally and it seemed to work

However the changes in master since my last push have been extensive and changed a lot of files I had modified, so I cannot emphasize enough, please do test thoroughly if you plan to merge this - I welcome any feedback and I'll fix problems if you are kind enough to report them. There's a real possibility I overlooked something and I'd be grateful for your time testing it.

[mutatrum]

Thank you for rebasing. I did a brief test, with merged master, and found some small things:

• I can access my device perfectly fine on hostname alone, without the .local suffix, as with any other local device on my network. In the code however, .local is added and shown on the dashboard and swarm. Somehow I can't really find where that is re-added if I try to remove it from the settings.
• When clicking on a host in swarm, it's opened by IP address.
• When updating the hostname, I got a warning in the logs: W (506261) CORS: IP address string is too long: bitaxe-gamma-601

[mutatrum]

Ah, found it in https://github.com/bitaxeorg/ESP-Miner/pull/1240/changes#diff-b92a1982bb82df47ec29d7c8b425023f334ec820176646b59970905c61ebc5e4R869.

As .local is not a universal standard, maybe we should let people use the suffix they need, or no suffix at all. I used to have a router that had .home as suffix, and as said above, my current LAN works without suffix.

I tested with line 866-881 in http_server.c commented out, so it just exposes hostname to the API, and it seems to work fine. API works, it shows just hostname without suffix in the top left and on swarm.

[camalolo]

Hello @mutatrum - thanks for taking the time to test and give feedback, I will have a look !

On my LAN I can also find hosts via the hostname only, but I think it's because of netbios resolution (so mostly windows PCs). You can see linux machines without a .local domain ? Any chance it's because you have samba installed with netbios enabled ?

It could also be your router that automatically adds them to its dns server.

As far as I understand, mDNS standards require .local : https://datatracker.ietf.org/doc/html/rfc6762

Also noted your other findings, will work on those as well

[mutatrum]

On my Linux machine I can see almost anything without .local: other Linux machines, Windows laptop, android tv, phones, printer, sonos, routers.

So maybe the mDNS announcement should indeed have .local but it might be possible to not show that, so it's only an internal thing? Depending if the front-end is opened on .local or hostname only, its seamless either way.

I haven't tested this with multiple mDNS Bitaxes, will do that as well.

[mutatrum]

Oh, by default hostname is set to bitaxe through the config. What happens if the hostname is already in use and there's a conflict? And same question for when changing the hostname to something that's already in use, how is that handled?

[camalolo]

Oh, by default hostname is set to bitaxe through the config. What happens if the hostname is already in use and there's a conflict? And same question for when changing the hostname to something that's already in use, how is that handled?

Excellent points, will try and solve these as well

[camalolo]

Hello @mutatrum ! I updated the code to take into account your remarks. For now, the mDNS will still use the .local suffix, as I couldn't find any evidence that this is not the standard.

But I believe I handled possible conflicts (two devices called bitaxe for example), fixed the CORS problem, allowed browsing the device via a basic hostname (i.e "bitaxe") if that resolves on your LAN, and improved the flow when you change the hostname via the network settings page.

I tried to test all situations I could think of, however, as usual, a fresh pair of eyes might uncover issues I did not encounter or think of.

Thanks for taking the time to test it !