MAC address is not reported to serial console when NerdMiner is started. It is reported what is name of AP that NerdMiner will connect, IP address is reported but MAC address is missing...
Other important information (that is not reported) is device name, it is used by DHCP client. DHCP server uses that name and creates entry in local DNS server, like in this example:
$ host 192.168.3.146
146.3.168.192.in-addr.arpa domain name pointer esp32s3-8A2CE2.local.
$ host esp32s3-8A2CE2.local
esp32s3-8A2CE2.local has address 192.168.3.146
It will be nice to report MAC address and device name to serial console during miner start and be accessible on display on devices with a screen, maybe new screen with device information, MAC address, IP address, DeviceID, device name, mining pool, wallet, worker name, mining password (it is not secret, it is "x" or some extra mining parameters)...
MAC address is important for troubleshooting WiFi or DHCP issues, to define access policy on WiFi AP points, for configuration management, for device evidence, etc.
MAC address can be found at WiFi admin interface (http://192.168.4.1/info) but to access it, NerdMiner configuration has to be erased. Other way to find MAC address is to find IP address of NerdMiner (it is reported to the serial console) then ping it from some computer connected to the same AP (or subnet) and find MAC address from ARP table.
There are two MAC addresses assigned to the device, these differ in the first byte, one bit difference:
T-DISPLAY-S3 has these MAC addresses:
84:FC:E6:12:34:56 - Station MAC
86:FC:E6:12:34:56 - AP MAC
ESP-WROOM-32 has MAC addresses assigned in different way, they differ in other bit
A0:A3:B3:12:34:56 - Station MAC
A0:A3:B3:12:34:57 - AP MAC
It seems that ChipID reported in WiFiManager is based on MAC address, 4 highest bytes of MAC are combined in reversed order, for MAC address A0:A3:B3:12:34:56 is chipID 12b3a3a0; that means, there are several (thousands?) devices with the same ChipID... :-(
An example script for Linux, find MAC address associated with IP address:
$ sh findmac.sh 192.168.3.154
PING 192.168.3.154 (192.168.3.154) 56(84) bytes of data.
64 bytes from 192.168.3.154: icmp_seq=1 ttl=255 time=180 ms
--- 192.168.3.154 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 179.572/179.572/179.572/0.000 ms
esp32s3-7521D7.local (192.168.3.154) at 34:85:18:75:21:d7 [ether] on eno1
I run KISMET scanner for several days; it is a Linux box with USB dongle with chip RT5370 and external WiFi antenna. I noticed that it detected that several WiFi devices are vulnerable from deauthentication attack. So I was collecting MAC addresses to find what devices have this issue. I see that these devices are NerdMiners, ESP32 and ESP32-S3 devices. When this happens, KISMET detects new Ad-Hoc type AP and that is NerdMiner). It is rare event but it is detectable... It is possible that this report is false positive but I recorded several cases and all these devices are NerdMiners... It is even possible that there is an issue with my AP (OpenWRT based but old firmware) and the issue has nothing to do with NerdMiners... MFP
Message reported by Kismet scanner:
NOCLIENTMFP IEEE80211 network BSSID 18:A6:F7:11:22:33 client 34:85:18:11:22:33 does not support management frame protection (MFP) which may ease client disassocation or deauthentication
NerdMinerV2, fw 1.6.3
MAC address is not reported to serial console when NerdMiner is started. It is reported what is name of AP that NerdMiner will connect, IP address is reported but MAC address is missing...
Other important information (that is not reported) is device name, it is used by DHCP client. DHCP server uses that name and creates entry in local DNS server, like in this example:
It will be nice to report MAC address and device name to serial console during miner start and be accessible on display on devices with a screen, maybe new screen with device information, MAC address, IP address, DeviceID, device name, mining pool, wallet, worker name, mining password (it is not secret, it is "x" or some extra mining parameters)...
MAC address is important for troubleshooting WiFi or DHCP issues, to define access policy on WiFi AP points, for configuration management, for device evidence, etc. MAC address can be found at WiFi admin interface (http://192.168.4.1/info) but to access it, NerdMiner configuration has to be erased. Other way to find MAC address is to find IP address of NerdMiner (it is reported to the serial console) then ping it from some computer connected to the same AP (or subnet) and find MAC address from ARP table.
There are two MAC addresses assigned to the device, these differ in the first byte, one bit difference:
T-DISPLAY-S3 has these MAC addresses:
84:FC:E6:12:34:56 - Station MAC 86:FC:E6:12:34:56 - AP MAC
ESP-WROOM-32 has MAC addresses assigned in different way, they differ in other bit
A0:A3:B3:12:34:56 - Station MAC A0:A3:B3:12:34:57 - AP MAC
It seems that ChipID reported in WiFiManager is based on MAC address, 4 highest bytes of MAC are combined in reversed order, for MAC address A0:A3:B3:12:34:56 is chipID 12b3a3a0; that means, there are several (thousands?) devices with the same ChipID... :-(
An example script for Linux, find MAC address associated with IP address:
Find MAC address for IP address 192.168.3.154:
I run KISMET scanner for several days; it is a Linux box with USB dongle with chip RT5370 and external WiFi antenna. I noticed that it detected that several WiFi devices are vulnerable from deauthentication attack. So I was collecting MAC addresses to find what devices have this issue. I see that these devices are NerdMiners, ESP32 and ESP32-S3 devices. When this happens, KISMET detects new Ad-Hoc type AP and that is NerdMiner). It is rare event but it is detectable... It is possible that this report is false positive but I recorded several cases and all these devices are NerdMiners... It is even possible that there is an issue with my AP (OpenWRT based but old firmware) and the issue has nothing to do with NerdMiners... MFP
Message reported by Kismet scanner: